> it says: Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh
It also recommends a script: "Installation time script to install correct POSIX shell pathname".
But I wonder how they execute this script. So this is all crap. They should remove that and instead put in something like "you have to test your script on the platform where you deploy.".
The article is missing the one big problem I encountered at most: bin/sh instead of bin/bash or the wrong version of sh|bash.
As I mentioned earlier, the trick is to have no shebang.
If the first line of a file of shell commands starts with the characters "#!", the results are unspecified.
[...]
If the execve() function fails due to an error equivalent to the [ENOEXEC] error [...], the shell shall execute a command equivalent to having a shell invoked with the pathname resulting from the search as its first operand, with any remaining arguments passed to the new shell, except that the value of "$0" in the new shell may be set to the command name.
"/usr/bin/env" is relying on a binary being present in a specific location just as much as relying on a binary being present in "/bin/bash". For most distros and BSDs, "/usr/bin/env" is more likely to be present, but it's not guaranteed for neither "/bin/bash" nor "/usr/bin/env".
Distros that places symlinks to bash in all those locations solves this, and allows all POSIX-compliant shebangs for sh and bash. On Arch Linux, /bin/bash, /bin/sh and /usr/bin/sh all point to /usr/bin/bash.
Nope. On the contrary, it says: Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh
Source: http://pubs.opengroup.org/onlinepubs/009695399/utilities/sh....
A pedantically-compliant shell script should not have shebang at all.