I'm really surprised they went with:
#!/bin/bash
as opposed to:
#!/usr/bin/env bash
the latter feels more flexible and dependable for a script to be passed around.
#!/bin/bash
as opposed to:
#!/usr/bin/env bash
the latter feels more flexible and dependable for a script to be passed around.
People who share code for the world to use should use:
- `#!/usr/bin/env bash`
- or `#!/bin/sh` for POSIX shell scripting
edit: bourne again shell
Never once have I ever seen this. In 25+ years.
- it works
- it's simple
- they know that bash is in /bin
- maybe it avoids a needless call to env, resulting in better startup time (see e.g. https://news.ycombinator.com/item?id=16978932 for a similar situation with python)
Why is it better than the other statement?
Thanks!
/bin/bash breaks on FreeBSD, which installs Bash at /usr/local/bin/bash. /usr/bin/env bash works though.
> You also can't pass command line arguments.
Are you sure about that? Given this script:
#!/usr/bin/env bash
echo "args: $@"
$ ./foo 1 2 3
args: 1 2 3
Good point about freebsd - I remember running into that exact problem. But I think I just symlinked it.
https://unix.stackexchange.com/questions/29608/why-is-it-bet... has more info on the pitfalls.
In my experience env causes problems, whereas explicit binary call always works (assuming the path exists). Not sure why I was downvoted.
EDIT: -e causes bash to exit on the first command that returns with an error (returns with a non-zero return code). It's documented in `man bash` where it documents the `set` builtin command.
> All of the single-character shell options documented in the description of the set builtin command can be used as options when the shell is invoked.
It's easy to miss though, when one's accustomed to quickly searching with "/".
EDIT: On the imagined env, it might be possible. I wonder what aspects of shebangs are portable across the various unix derived OSs. It may be that there's some systems where it only takes non-whitespace characters as the first argument and drops everything else after encountering another space. There might be also other limitations that one should consider when making more use of shebangs, like the character limit of the lines. For example, I think linux only takes the first 127 characters of the shebang and ignores everything else; other systems might take less. I encountered that limit when writing this answer:
https://unix.stackexchange.com/questions/365436/choose-inter...
EDIT 2: If you were to do such a program, it will probably also need to implement quoting and escaping syntax. The difficult part is that, since it wouldn't be a standard program to have, it'd have to be listed as a dependency of whatever projects you use it in, and I wonder if the benefit really outweighs the cost of having yet another dependency. I can't see something like this gaining wide adoption.
#!/usr/bin/env --new-env-behavior-parse-all-args=bash -e
Makes sense. Thanks for clarifying. I had a feeling I wasn't understanding your point.
#!/usr/bin/env bash -ex
#!/bin/bash -exIts not a ruby thing, its the way you're supposed to write portable scripts where the location of the executable might not be predetermined. Lets say you're on a distribution where bash is in /usr/bin/bash instead of /bin/bash. Well you'll be modifying the shebang line to either do /usr/bin/env bash or pointing it to that spot.
What old systems didn't it work on? I've used everything from SunOS, Irix, HPUX, AiX, Solaris, Linux, bsd's, anything claiming to be posix has to support that.
I run into this trying to run rvm-managed Ruby scripts in cronjobs. The solution (IIRC) is to explicitly reference the interpreter you want to run in the cronjob line.
/usr/bin/env is not POSIX anymore than /bin/bash etc.
Mentions that the env command is POSIX, but it doesn't mention the absolute path. Are you saying that /use/bin/env is not POSIX because there is no guarantee that it will be available at that particular path?
> Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.
EDIT: I wondered what POSIX recommended to do for any use of the shebang and this is what I found:
> Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed).
Wow.