Live data from Hacker News

Shell Style Guide

google.github.io

21–30 of 336 posts

Re: Shell Style Guide

#21

>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?

Google also makes it difficult to compile Chromium on platforms where /usr/bin/python is python 3, because their shebangs are:

    #!/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

Re: Shell Style Guide

#22
post #4
post #2

> Shell should only be used for small utilities or simple wrapper scripts. Oh you mean we weren’t supposed to write an etl solution in bash?

I’ve actually seen this happen. It’s terrifying.

You don't know true terror.

I've seen an "ETL" solution (minus the "T") written entirely in SQL but using XML instead of tables and columns. After traveling through multiple servers via OpenQuery it eventually gets loaded into a domain-specific piece. That piece passes the data into a frontend that can only run in quirks mode.

That frontend has 60-80 separate projects that all parse out basically the same data but from different fields and with different parsing/mapping logic. There is no ability to load shared libraries or otherwise de-duplicate code and no authorization to call out to any internal web services that could be written to handle it. Nor is there any form of templating available, it's all static files with no nesting of folders allowed. And the whole thing is managed in a domain-specific editor that effectively precludes the use of version control thanks to the way it stores files.

Two people are responsible for managing that frontend piece and more.

Re: Shell Style Guide

#23

>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?

I don't feel as strongly about it as Sir_Cmpwn does but I agree with him. The logic goes something like: you should only use shell scripts for small scripts and not complex applications. Ergo the added functionality of bash scripts should not be necessary anyway and might actually lead you to believe that it's a proper programming language.

Or to put it the other way around: if you find yourself writing a POSIX shell script and find that you'd like to use more advanced features then one of two things can happen:

- You need portability to SunOS 4, so you suck it up and keep hacking your script because bash is not an option anyway;

- You don't need portability, so then why not use a proper programming language like python, perl or ruby rather than upgrading from crappy sh to slightly-less-crappy bash?

Re: Shell Style Guide

#24
post #7

Earlier quoted context omitted.

It's not creepy if you wrote it while working at google (as a mathematician, i couldn't help but notice that you are not excluding this possibility).

S/he did exclude this possibility by saying "I've never seen this guide before today" :-)

Maybe koolba was blind and has been cured.

Re: Shell Style Guide

#25
> If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python.

This is exactly why I wrote my last script in Python. I started googling for how to do some simple stuff with arrays in Bash and after 10 minutes decided "I'll write it in Python".

Re: Shell Style Guide

#26
post #5

The only thing I'd quibble with is the recommendation of [[ ... ]] over [ ... ], because shell programmers used to [ will be surprised that [[ "foo" == "f*" ]] does pattern matching. But that is more or less an arbitrary style preference. One thing I'm curious about is whether Google machines have followed Debian etc. in making /bin/sh a faster non-bash shell, or if /bin/sh is bash.

> will be surprised that [[ "foo" == "f*" ]] does pattern matching

It will not do pattern matching, because you quoted the right-hand side.

Re: Shell Style Guide

#27

>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?

Probably because he can't use bash code in his BusyBox based router

Re: Shell Style Guide

#28

>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…

You're getting voted down (likely for only saying the article is wrong but not why), but I'm curious your reasoning. I've tended to write in POSIX sh (for maximum compatibility - and because it was just the way I learned) - but am happy to use bash too when the project allows and it makes sense so not sure I get the hard line stance. Wondering what I might be missing to evoke such a response.

I wrote in some greater detail in response to someone else:

https://news.ycombinator.com/item?id=17073703

Re: Shell Style Guide

#29
post #4

Earlier quoted context omitted.

I’ve actually seen this happen. It’s terrifying.

You don't know true terror. I've seen an "ETL" solution (minus the "T") written entirely in SQL but using XML instead of tables and columns. After traveling through multiple servers via OpenQuery it eventually gets loaded into a domain-specific piece. That piece passes the data into a frontend that can only run in quirks mode. That frontend has 60-80 separate projects that all parse out basically the same data but fr…

Sounds very much like IBM AS400

Re: Shell Style Guide

#30
post #19

Earlier quoted context omitted.

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?

Maybe one day there will be another cool and dominating shell. That shell is more likely to be POSIX compliant than bash compliant.

[deleted]
Post reply on HN