7 ms·
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
by _arvin 8y ago
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.
- moviuro 8y agoIt is, but don't forget it's a guide for Google engineers on the Google machines. People who share code for the world to use should use: - `#!/usr/bin/env bash` - or `#!/bin/sh` for POSIX shell scripting
- peterwwillis 8y ago/bin/sh is most often either the C shell, Dash, or Ash, not the Bourne shell. Bourne shell extensions will cause the script to fail. edit: bourne again shell
- moviuro 8y agoYou certainly meant /bin/sh is not the Bourne again shell. I updated my comment to clear any possible misunderstanding https://en.wikipedia.org/wiki/Bourne_shell https://en.wikipedia.org/wiki/Bourne_shell https://en.wikipedia.org/wiki/Bourne-again_shell https://en.wikipedia.org/wiki/Bourne-again_shell
- floatboth 8y ago/bin/sh shouldn't be a C shell, it's always a POSIX-compatible shell IIRC
- peterwwillis 8y agoI suppose you're right, though the main point is it may not have Bourne-again extensions
- scruple 8y agoIn the wild, hopefully not, but I do remember coming across /bin/sh executing csh in an obscure RTOS-ish / proprietary flavor of Linux that we were prototyping at a previous employer. Would've been around 2008. I can't remember the variant, but I remember being caught off-guard by it.
- gkya 8y agoAFAIK /bin/sh is standard; if you cannot trust that /bin/sh is a Bourne-like sh, you might as well have to assume /usr/bin/env can not be what it was meant to be too.
- deleted 8y ago[deleted]
- cowmoo728 8y agoI once triggered an automatic deploy that ran a bash script that minified a bunch of css/html/js assets and pushed them to S3, at some path like `/assets/vX.X.X/whatever.css`. Unfortunately, a few of our deploy boxes had Dash instead of Bourne shell, and when it ran on dash it failed to parse the version tag to push and ended up pushing an empty dir to /assets - deleting everything. Fun experience.
- michaelcampbell 8y ago> /bin/sh is most often either the C shell, Never once have I ever seen this. In 25+ years.
- h1d 8y agoDoesn't explain why Google wouldn't use env unless there's a good reason to avoid env.
- moviuro 8y agoTop of my head: - 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 https://news.ycombinator.com/item?id=16978932 for a similar situation with python)
- nvarsj 8y agoI really don't like the `/usr/bin/env bash` approach (it came from the ruby world I think?). It's less portable than /bin/bash in my experience - I've been in environments, usually older ones, where it doesn't work at all. But /bin/bash works everywhere. You also can't pass command line arguments. And it's slightly more complex than just invoking /bin/bash.
- davidcuddeback 8y ago> It's less portable than /bin/bash in my experience /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: $@" it outputs: $ ./foo 1 2 3 args: 1 2 3 Is that what you meant?
- nvarsj 8y agoYou can do “/bin/bash -e” but not “/usr/bin/env bash -e”. Same for python etc. 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-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my/29620#29620 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.
- jessaustin 8y agoIs this a problem with env? What does the "-e" flag do anyway? "man bash" proved unenlightening.
- jolmg 8y agoIt's not because of env. It's just that shebangs are limited to passing one optional argument to the executable specified. The way they're parsed is the executable path, and if there's a space, then the rest of the line (including any additional spaces) is interpreted as 1 argument to the executable. 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.
- billhathaway 8y agoGoogle's linux systems are standardized, there isn't a concern about running a script on 10 different OS variants
- hi41 8y agoCould you please explain what #!/use/bin/env bash does? Why is it better than the other statement? Thanks!