>Bash is the only shell scripting language permitted for executables. Whelp, wrong right off the bat. I'm gonna get down my my knees here and beg everyone reading: use POSIX shell. Do not write scripts with bash. Do not write scripts with zsh. Do not write scripts with fish. Use POSIX shell. sh has a really bad interactive mode (so does bash), so I'm not gonna give anyone a hard time for using another shell as their…
I'm genuinely curious, why? If you're writing generic scripts designed to run across multiple platforms then fine, but in the context of Google (or most other companies) they'll have a standard set of tooling available on all their machines, which presumably includes Bash if they're making that statement. What about POSIX shell makes it superior for scripting?
#!/usr/bin/env python
Rather than the more portable: #!/usr/bin/env python3
Notably this causes problems for people on Arch Linux, and in the near future, Fedora. This post is presented as a style guide that others should adopt. Google may have bash ubiquiotously available internally, but their approach should not be taken as a model for others. Google's approach has caused real problems for their software's portability in exchange for dubious value-adds.>What about POSIX shell makes it superior for scripting?
To address this specifically, I have written a blog article on the subject:
https://drewdevault.com/2018/02/05/Introduction-to-POSIX-she...
The main points are:
- bash is far from as ubiquitous as some people seem to think it is
- sh is formally standardized and has multiple competing implementations, whereas bash is defined by its implementation and there is only one
- sh is perfectly competent and easy to target, bash's value add is questionable
- By the time you need the things bash offers you might as well not use a shell script at all