"One example of this is Solaris SVR4 packages which require plain Bourne shell for any scripts."
Such as?
Shell Style Guide
11–20 of 336 posts
Re: Shell Style Guide
#12The 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.
Same here. Dropping non-bash support just for [[ ... ]] over [ ... ] seems a little odd.
Re: Shell Style Guide
#13>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.
Re: Shell Style Guide
#14Earlier quoted context omitted.
I’ve actually seen this happen. It’s terrifying.
Sure, but not as terrifying as people rewriting shell one-liners in python or (gasp) java.
I have been there, porting ksh scripts to Java.
As much as I might like Java, this surely did not make any sense, but when people want to pay you for doing it, oh well.
Re: Shell Style Guide
#15I've never seen this guide before today but skimming through I absolutely love it. It aligns with my exact bash scripting style. Everything from the variable and function naming rules, stderr logging, pipeline indentation, and even having a "main () { ...}" wrapper and invocation. It's almost creepy!
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).
[deleted]
Re: Shell Style Guide
#16I've never seen this guide before today but skimming through I absolutely love it. It aligns with my exact bash scripting style. Everything from the variable and function naming rules, stderr logging, pipeline indentation, and even having a "main () { ...}" wrapper and invocation. It's almost creepy!
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" :-)
Re: Shell Style Guide
#17Earlier quoted context omitted.
I’ve actually seen this happen. It’s terrifying.
Sure, but not as terrifying as people rewriting shell one-liners in python or (gasp) java.
Then a lot of people don’t understand the limits of what they’re doing.
For instance piping though commands works fine until one character sequence is interpreted as EOF. The fun part is it will work most of the time, and when it fails nobody will understand why (“we didn’t touch anything”), and rewriting the thing will be a political nightmare (“it was working before and was only 3 lines, why you need so much time to redo it ?”)
I think most people (me included) don’t do enough shell programming to really know the trade-off of the one-liner vs doing it in groovy, so the latter becomes the safer option (rightly so IMO)
Re: Shell Style Guide
#18I absolutely hate coding in bash or looking at bash or suddenly being in Windows and being up a tree because bash isn't supported well (it is now if you install WSL). I only use bash to set environment variables and maybe string together 2 or 3 build commands. If I need so much as an if statement, I'm going to switch to a real programming language.
Re: Shell Style Guide
#19>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?
Maybe one day there will be another cool and dominating shell. That shell is more likely to be POSIX compliant than bash compliant.
Re: Shell Style Guide
#20Earlier quoted context omitted.
I’ve actually seen this happen. It’s terrifying.
Sure, but not as terrifying as people rewriting shell one-liners in python or (gasp) java.
Well, rewriting one liners is kind of stupid, but it's probably not going to result in a nearly incomprehensible mess running in production.