Jookia <166...@gmail.com> 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 #!@BASH@ (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’.
