A surprise with how '#!' handles its program argument in practice
22 comments
·November 18, 2025jolmg
saurik
Or, like, if you aren't reading and caring about what the interpreter is--as that's the only time this can burn you: it isn't doing a PATH lookup, so you can't walk into this one on accident--then it could literally be something like /bin/rm on some key file. This entire article is based on an assumption that this is somehow so obviously bad that there doesn't even need to be an explanation or defense of any kind of that idea.
tombert
Huh. I wish I had known this before.
NixOS is annoying because everything is weird and symlinked and so I find myself fairly frequently making the mistake of writing `#!/bin/bash`, only to be told it can't find it, and I have to replace the path with `/run/current-system/sw/bin/bash`.
Or at least I thought I did; apparently I can just have done `#!bash`. I just tested this, and it worked fine. You learn something new every day I guess.
nflekkhnnn
Anything other than ”#!/usr/bin/env bash” is doomed to fail at some time.
normie3000
And is this shebang guaranteed to work always? Why isn't it more common?
jolmg
Because /bin is the standard location for bash. The only one that breaks that expectation is NixOS (and maybe GuixSD?), apparently. I'm surprised they didn't symlink /bin or put a stub. Last time I tried NixOS was like 10 years ago. I thought there was a /bin/bash, but maybe it was just a /bin/sh?
Other interpreters like python, ruby, etc. have more likelyhood of being used with "virtual environments", so it's more common to use /usr/bin/env with them.
int_19h
It's guaranteed to work provided that Bash is in the path.
It's very common for Python. Less so for Bash for two reasons: because the person who writes the script references /bin/sh instead (which is required to be there) even when they are writing bash-isms, or because the person who writes the script assumes that Bash is universally available as /bin/bash.
eyelidlessness
It’s quite common, although I probably see it used more frequently to invoke other (non-shell) scripting languages.
saintfire
You can use `#!/usr/bin/env bash` on NixOS
tombert
I didn't know that actually. I'll start using that from this point forward.
miffe
Seems like it only works in zsh, not bash or fish
tombert
[tombert@puter:~/testscript]$ ./myscript.sh
bash: ./myscript.sh: bash: bad interpreter: No such file or directory
adastra22
Is this UNIX?
adastra22
The kernel interprets the shebang line, not the shell.
jolmg
It is possible for the shell to handle it. From zshall(1):
> If the program is a file beginning with ‘#!', the remainder of the first line specifies an interpreter for the program. The shell will execute the specified interpreter on operating systems that do not handle this executable format in the kernel.
Taking a quick look at the source in Src/exec.c:
execve(pth, argv, newenvp);
// [...]
if ((eno = errno) == ENOEXEC || eno == ENOENT) {
// [...]
if (ct >= 2 && execvebuf[0] == '#' && execvebuf[1] == '!') {
// [...]
(pprog = pathprog(ptr2, NULL))) {
tombert
I'm not sure the reason then, but they're definitely right; it works fine with zsh, doesn't work with bash. I wrote a test script to try it myself.
I don't have fish installed and can't be bothered to go that far, but I suspect they're right about that as well.
Crestwave
`#!/usr/bin/env bash` is the most portable form for executing it from $PATH
hamandcheese
Is this meaningfully more portable than #!bash though?
tombert
In a sibling thread someone pointed out that #!bash doesn't actually work if you're calling it from bash, and appears to only work with zsh.
I just tried it and they were absolutely right, so `#!/usr/bin/env bash` is definitely more portable in that it consistently works.
saurik
This mechanism doesn't do a PATH lookup: #!bash would only work if bash was located in your current working directory.
> Although this is probably the easiest way to implement '#!' inside the kernel, I'm a little bit surprised that it survived in Linux (in a completely independent implementation) and in OpenBSD (where the security people might have had a double-take at some point). But given Hyrum's Law there are probably people out there who are depending on this behavior so we're now stuck with it.
I don't see what there would be to gain in disallowing the program path on the shebang line to be relative. The person that wrote the shebang can also write relative paths in some other part of the file.