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

131–140 of 336 posts

Re: Shell Style Guide

#131

Post by sametmax »

pas wrote: post #81
bitlax wrote: post #49

Earlier quoted context omitted.

This document agrees with you. - If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python. - If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.

Exchanging Bash for Python is a folly. Python seems to handle complexity better, but only on the surface. (Basically Python has nice data structures, great string formatting, and .. that's it.) Setting up the Python environment requires something, because Python comes in many flavors (2 vs 3, system installed, user installed, /usr/local) and there are a bunch of factors (pip, pyenv, pipenv, PYTHONPATH, current direct…

They have a standard setup everywhere, with the same Python version, and the same libs available.

So basically, for them, Python requires no fiddling and works as is.

Same for the shell. They say "use [[]]" because they know that compat is not a problem: it's the same bash everywhere.

Google has millions of servers, billions of lines of code and surely of lot of experience with deployment, managing complexity and handling teams.

I'm kinda trusting them on this choice.

Re: Shell Style Guide

#132

Post by WalterBright »

bitlax wrote: post #49
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.

This document agrees with you. - If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python. - If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.

D can be used as a scripting language:

    #! /usr/bin/env rdmd
    import std.stdio;
    void main() { writeln(2); }
Just add the shebang line. https://wiki.dlang.org/Why_program_in_D#Script_Fan

Re: Shell Style Guide

#133

Post by alecbenzer »

Sir_Cmpwn wrote: post #73
moviuro wrote: post #44

Earlier quoted context omitted.

> >Bash is the only shell scripting language permitted for executables. > Whelp, wrong right off the bat. It really is a Google guide, tailored to Google engineers. If they know for sure that bash is available on any *n?x machine, then why not? It's just a local policy. And if it's that much of a problem, the other places where you get bash instead of POSIX sh from Google (chromium?) the license clearly allows you to…

>It really is a Google guide, tailored to Google engineers. And posted in a public forum, which is why I made sure to protest its adoption by the broader public.

I don't get that from "Whelp, wrong off the bat", which seems to imply that there is a more unambiguous right answer here, and Google is wrong for deviating from it.

Re: Shell Style Guide

#134

Post by Sir_Cmpwn »

joshuamorton wrote: post #128
Sir_Cmpwn wrote: post #111

Earlier quoted context omitted.

https://www.python.org/dev/peps/pep-0394/

That, unfortunately, only works if you don't need to maintain backwards compatibility with older systems. `python` will exist and point to python2 on any system. `python2` may not if it predates or ignores the PEP. `python3` didn't even come installed by default on a lot of nixes until recently, making it the worst of option of the three.

Of course, it will take time for this to become effective. But this is the portable solution. Systems for which this does not work are broken and should be fixed, software should not be updated to accomodate for broken systems.

Re: Shell Style Guide

#135

Post by pas »

taesis wrote: post #123
pas wrote: post #81

Earlier quoted context omitted.

Exchanging Bash for Python is a folly. Python seems to handle complexity better, but only on the surface. (Basically Python has nice data structures, great string formatting, and .. that's it.) Setting up the Python environment requires something, because Python comes in many flavors (2 vs 3, system installed, user installed, /usr/local) and there are a bunch of factors (pip, pyenv, pipenv, PYTHONPATH, current direct…

Re. a recommended alternative to quick and dirty bash scripts, do you think golang would do? I've barely dabbled with the language, but its default packaging (a single, static binary) and build system (`go build x`) seem well suited to rapid setup, deployment and testing, which is presumably what you'd want in this scenario.

Many people use go for such things. I simply don't like go, it's too crude (too C), and the packaging system is. Well, it's not Cargo.

But probably for deploy scripts, go with a static binary (hosted on, let's say your GitLab instance - using the GitLab HTTP API with a token to wget/curl it) is nigh unbeatable in end-to-end development and deployment time.

Re: Shell Style Guide

#136

Post by Sir_Cmpwn »

alecbenzer wrote: post #133
Sir_Cmpwn wrote: post #73

Earlier quoted context omitted.

>It really is a Google guide, tailored to Google engineers. And posted in a public forum, which is why I made sure to protest its adoption by the broader public.

I don't get that from "Whelp, wrong off the bat", which seems to imply that there is a more unambiguous right answer here, and Google is wrong for deviating from it.

Well, even within Google I think this policy is stupid. Any software they make open source or have to port to new platforms that was based on this policy is going to break, and for what? Bashisms provide a dubious value-add.

Re: Shell Style Guide

#137

Post by mitchty »

nvarsj wrote: post #105
_arvin wrote: post #69

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.

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

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

Its not a ruby thing, its the way you're supposed to write portable scripts where the location of the executable might not be predetermined. Lets say you're on a distribution where bash is in /usr/bin/bash instead of /bin/bash. Well you'll be modifying the shebang line to either do /usr/bin/env bash or pointing it to that spot.

What old systems didn't it work on? I've used everything from SunOS, Irix, HPUX, AiX, Solaris, Linux, bsd's, anything claiming to be posix has to support that.

Re: Shell Style Guide

#138

Post by int0x80 »

pas wrote: post #81
bitlax wrote: post #49

Earlier quoted context omitted.

This document agrees with you. - If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python. - If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.

Exchanging Bash for Python is a folly. Python seems to handle complexity better, but only on the surface. (Basically Python has nice data structures, great string formatting, and .. that's it.) Setting up the Python environment requires something, because Python comes in many flavors (2 vs 3, system installed, user installed, /usr/local) and there are a bunch of factors (pip, pyenv, pipenv, PYTHONPATH, current direct…

Agree. If you want to do shell work in something closer to the shell and have a real programming language, Perl is the winner.

Re: Shell Style Guide

#139

Post by geofft »

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.

... ... okay, now I extremely object to [[ "foo" == f* ]] not doing globbing and doing pattern matching. But, I guess Google folks have experience that this is non-confusing?

Re: Shell Style Guide

#140

Post by ianbicking »

falsedan wrote: post #117
benmmurphy wrote: post #36

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

`set -e` is basically a way to find where you need better error-handling, not a way to make scripts safe. I'd much rather a crummy script run into trouble calling some new featuref, shrug, and move on to the core business-critical code, instead of erroring out and triggering a bunch of pages.

Do you normally protect every command with || exit?

    cd foobar || exit
It's those really small failures that cause shell scripts to do crazy things without set -e.
Post reply on HN