[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thesis: guixsd should provide /usr/bin/env
From: |
Ludovic Courtès |
Subject: |
Re: thesis: guixsd should provide /usr/bin/env |
Date: |
Mon, 29 Feb 2016 10:41:55 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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’.