Re: thesis: guixsd should provide /usr/bin/env

[Ludovic Courtès]

Jookia <address@hidden> skribis:

> That said, I think it's the wrong approach since it's automated, invisible and
> hides the issues of /usr/bin/env. Instead we need to do two things:
>
> Write some scripts to ease migration and documentation on how to use Autotools
> or other tools to fix shebangs. This is portable and will work on all systems.
> Basically, find all shebangs, replace them with a macro that expands to the
> binary, move the file from 'name.sh' to 'name.in.sh' and then use 
> './configure'
> or 'make' to build the 'name.sh' scripts with fixed shebangs.

I think projects already do that (or at least, They Should Be Doing
That.)  That is, either any Bourne shell is fine, and they use
#!/bin/sh, or they require Bash specifically, and they use AC_PATH_PROG
and address@hidden@ (same for Python, Perl, etc.)

Now, reality is that there’s probably a lot of typically small packages
that use hard-coded shebangs.

> Write a script that patches shebangs in a directory tree and has support for
> unpatching them. This is useful for developing or running unpatched third 
> party
> trees where you want to change the source code and submit patches without
> actually fixing the problem.

I think patching is perfect in our build environment (the
‘patch-shebangs’ and related phases), but probably inconvenient when
working on another project where it may force you to carry a patch
forever.  ISTR that Andy mentioned working on WebKit or Chromium, which
has hard-coded shebangs, and where patching things is annoying at best.

The ‘binfmt_misc’ hack (or other hacks to that effect) can be helpful in
those cases.

Ludo’.