Hi, I'm surprised that no one pointed it out to the obvious and correct fix for this sort of situation instead of taking the easy route and just adding a symlink or using a hack in the runtime loader. In the build system of the software (here LLVM) the shell scripts must be changed to be ".in" files which are processed at build time to generate (usually with 'sed') the final script to be installed with the adequate shebang line for the system for which LLVM is being built. If you do it this way, I don't see any (good) reason why upstream won't accept the patches. Bye, On Sat, Oct 12, 2013 at 11:22 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>wrote: > On 10/12/2013 01:27 AM, John Scipione wrote: > >> http://unix.stackexchange.com/**questions/29608/why-is-it-** >> better-to-use-usr-bin-env-**name-instead-of-path-to-name-**as-my<http://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my> >> > > Great that you actually started reading into the subject :-) > > > As the linked answer indicates, both #!/usr/bin/python and >> #!/usr/bin/env python are valid in different cases, at least on *nix >> systems. >> > > Sorry, you apparently misread that answer. > The important sentences are: > "By specifying #!/usr/bin/python you specify exactly which interpreter > will be used to run the script on a particular system." > And: > "I use an installer script that modifies the #! line of each script as it > installs it in my $HOME/bin." > > It is perfectly fine not to use /usr/bin/env for a particular system, or > when you write that line during installation. If you do that, then /usr has > no use, too, though, as you already know the target system when you do that. > /usr/bin/env is, while flawed, a solution to a problem, not something that > became widely used because someone was bored. > > Bye, > Axel. > > >