Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shell Style Guide

google.github.io

Post reply on HN
Print view View original

31–40 of 336 posts

Re: Shell Style Guide

#31

Post by wildmusings »

Sir_Cmpwn wrote: post #3

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

Portability doesn’t make sense for an operation like Google. Even if some new shell promises compatibility, you still have to test every single script against it. Why bother? Write scripts in bash, run them in bash. In the future, switch to whatever you want for new scripts.

Re: Shell Style Guide

#32

Post by cellard00r »

tootie wrote: post #18

I 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.

Often times it's easier to use binaries and manage their input/output through shell code.

Having a good understanding of shell code will also allow you to easily write slick one-liners that will save you lots of time.

Re: Shell Style Guide

#33

Post by oblio »

JepZ wrote: post #19
jon-wood wrote: post #10

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.

All the cool new shells I've seen are either completely POSIX incompatible (powershell, xonsh, etc.) or they try to be bash supersets (zsh, osh, etc.).

Bash is a de facto modern standard.

The only new purely POSIX shells I know are for embedded stuff (dash) and that space is neither fast moving nor in dire need of a better shell, since most modern shell features target interactive use. Or they make coding easier and/or safer, in which case we're back to point 1, with the POSIX incompatibility.

Re: Shell Style Guide

#34

Post by wildmusings »

Sir_Cmpwn wrote: post #21
jon-wood wrote: post #10

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?

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

Competing implementations sounds like a potential downside to me. That’s just more possible configurations where a bug could be hiding. Even if you use standard posix shell, you’d be wise to target a single implementation and stick to it.

Re: Shell Style Guide

#35

Post by [deleted] »

nurettin wrote: post #29
reificator wrote: post #22

Earlier quoted context omitted.

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

[deleted]

Re: Shell Style Guide

#36

Post by benmmurphy »

i'm surprised it doesn't recommend using set -e /other flags. [http://redsymbol.net/articles/unofficial-bash-strict-mode/] maybe it is not covered because it is not considered 'style' but i think those flags are some of the most important things you can set when writing a bash script. i guess if you are writing scripts that start other things, and then check their error codes it can be annoying because you have turn them off/on.

Re: Shell Style Guide

#37

Post by NiveaGeForce »

tootie wrote: post #18

I 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.

And on Windows there is something better than Bash, called PowerShell.

Re: Shell Style Guide

#38

Post by Already__Taken »

NiveaGeForce wrote: post #37
tootie wrote: post #18

I 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.

And on Windows there is something better than Bash, called PowerShell.

Which actually supports linux with PS 6.0+

Re: Shell Style Guide

#39

Post by Sir_Cmpwn »

wildmusings wrote: post #34
Sir_Cmpwn wrote: post #21

Earlier quoted context omitted.

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

Competing implementations sounds like a potential downside to me. That’s just more possible configurations where a bug could be hiding. Even if you use standard posix shell, you’d be wise to target a single implementation and stick to it.

So you think that competition between gcc and clang is harmful to the C and C++ ecosystems? If you find bugs in an implementation of POSIX sh, you should report it to that implementation. Multiple competing implementations is a sign of a good standard, it proves the standard's correctness and demonstrates its maturity.

There is no standard to hold bash to. Any strange behavior of it might be decided as by design and kept forever (and replicated by anything which tries to be bash compatible) or it could be determined to be a bug and, when fixed, break the scripts which worked around it or depended on it. There's no way to know how this is going to shake out because there is no objective specification for the language. At least when there's a bug in one of these competing sh implementations that you're so worried about, it's objectively a bug and can be fixed.

Re: Shell Style Guide

#40

Post by your-nanny »

dualbus wrote: post #26
geofft wrote: 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.

Which is totally fucking indane
Post reply on HN