> You're using a suspiciously old browser
Does the author not like Firefox or what?
A surprise with how '#!' handles its program argument in practice
51–60 of 116 posts
Re: A surprise with how '#!' handles its program argument in practice
#52Earlier quoted context omitted.
Anything other than ”#!/usr/bin/env bash” is doomed to fail at some time.
> Anything other than ”#!/usr/bin/env bash” is doomed to fail at some time. if you have /usr/bin/env
/usr/bin/env (and /bin/sh) are part of POSIX, that is why the above shebang is the recommended way to start a shell.
Re: A surprise with how '#!' handles its program argument in practice
#53Huh. 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…
> apparently I can just have done `#!bash` I think you're mixing two concepts: relative paths (which are allowed after #! but not very useful at all) and file lookup through $PATH (which is not done by the kernel, maybe it's some shell trickery).
> and file lookup through $PATH (which is not done by the kernel, maybe it's some shell trickery)
It's libc. Specifically, system(3) and APIs like execvp(3) will search $PATH for the file specified before passing that to execve(2) (which is the only kernel syscall; all the other exec*() stuff is in libc).
Re: A surprise with how '#!' handles its program argument in practice
#54Re: A surprise with how '#!' handles its program argument in practice
#55This insight came from perl5 btw.
Re: A surprise with how '#!' handles its program argument in practice
#56Earlier quoted context omitted.
Anything other than ”#!/usr/bin/env bash” is doomed to fail at some time.
> Anything other than ”#!/usr/bin/env bash” is doomed to fail at some time. if you have /usr/bin/env
I don't know if this is still a thing, but I distinctly remember when playing around with NixOS years ago that `env` was the only thing in /usr/bin, which I assumed was pretty much exactly for this reason.
Re: A surprise with how '#!' handles its program argument in practice
#57Historically FreeBSD used to split the #! argument list fully which meant you could put oneline scripts in there. At some point too many ports had to struggle with Linuxisms that this was changed to only split it into command and first argument. The old behaviour can be accessed with a flag in the env wrapper.
Re: A surprise with how '#!' handles its program argument in practice
#58What's suprised me is that there is a line length limit on #! for 256 bytes.
You can have spacing after #! for some reason?
POSIX does not mandate -S, which means any script that uses it will only work on freebsd/linux
Re: A surprise with how '#!' handles its program argument in practice
#59For personal use, I used to write #!perl to avoid the hassle of keeping track of the location of the binary across differing systems (although now I wonder if this only worked in the shell I ran under WinNT4—it’s been ages since I’ve done that sort of thing and these days I tend not to use #! at all to run scripts.)
Re: A surprise with how '#!' handles its program argument in practice
#60There's no security issue here. Certainly the OP hasn't explained why there is one.
There could be. Say you have '#!sh', someone could have put a broken 'sh' somewhere, that could be the first one the '#!' sees.