Use /usr/bin/env in shebang.

[ruediger]

On some distributions (e.g., NixOS) the bash binary is not in /bin/bash
and the perl binary not in /usr/bin/perl. Using /usr/bin/env in the
shebag instead should make it work.

[brendangregg]

Thanks; I developed these tools as possible inclusions under /tools in the Linux kernel. There are many existing shell and Perl programs already in that directory, however, none of them use env. Eg:

linux-3.16/tools# find . \( -name \*.sh -or -name \*.pl \) -exec head -1 {} + | grep '#!'
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/sh
#!/bin/sh
#!/usr/bin/perl -w
#!/usr/bin/perl -w
#!/usr/bin/perl -w
#!/usr/bin/perl -w
#!/bin/bash
#! /bin/bash
#!/bin/sh
#!/bin/bash
#!/bin/sh
#!/bin/sh
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/sh
#!/bin/sh
#!/bin/sh
#!/bin/bash
#!/bin/sh
#!/bin/sh
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/sh
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/bin/bash
#!/usr/bin/perl -w
#!/usr/bin/perl

Do you know why? I don't know, but here's some guesses:

• An unwillingness to waste the extra ~1ms of CPU time for env wrapping, which isn't necessary for most distributions. This is less of a problem since these tools should be interactive.
• An unwillingness to begin every program with what is essentially a hack -- using env for not its intended purpose -- because of some distributions.
• Do some distributions not provide env under /usr/bin?
• Security implications of executing from $PATH, especially since these tools are intended to be run as root. Although I doubt this is the case, having not seen "." in root's $PATH for over a decade.
• Something else?

Again, I don't know, but I'm trying to understand why none of the existing Linux /tools shell and Perl programs use env. Should they all switch to env?

[XANi]

Using env for bash script almost never makes sense as you rarely have custom bash version under your $PATH that you want to use.

It IS useful if you are running Perl/Python/Ruby script, as those are often used with tools (like perl brew or ruby RVM) that compile your own version of interpreter for various reasons(mostly being independent of distro version, or testing with same interpreter version that is running on production).

Those tools usually just complile under some $HOME/directory and then add it to the $PATH

TBH i would report it as a bug in distro. If some silly distro developer wants to put their standard binaries in weird locations so be it but distro should provide standard locations via a symlink or sth

[ruediger]

Do you know why?

I don't know either. But I'm assuming the reason is simply that almost all GNU/Linux distributions ship bash and sh in /bin. And even the distributions abandoning /bin and moving everything to /usr still seem to provide symlinks in /bin.

The use (or abuse) of env seems to be common for other scripting languages where the users, as @XANi said, is more likely to have their own version installed or for bash scripts which are supposed to run on non-GNU/Linux systems (clearly not the case here).

Not having a bash in /bin is probably a pretty NixOS specific problem (/design decision) when it comes to GNU/Linux distributions. NixOS tries to achieve reproducible builds and therefore doesn't use /bin or /usr/bin except for the env symlink.

I can understand if your concerns outweigh the support for NixOS.

[penberg]

@brendangregg I doubt there's any real reason for not using env and it's just kernel developers being lazy. 😉

[brendangregg]

We went through env adoption in BCC and then had to roll back due to issues (now the github history for every BCC tool shows this rollback, which gets annoying when you see it for the umteenth time.) I know it solves some problems, but it creates them as well. Closing.