I don’t understand all the hate for bash or python in this thread.

These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the way they did back then

Python is also a tool. I have written scripts in python to manage processes do forking etc and it too has some warts. It is also used by companies tohat deploy thousands of lines of code or more. Yes it isn’t statically typed and yes you can get into a box but guys no single language is objectively superior to another.

So learn them like you would any other tool and move on.

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.

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.

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.

This quote on whether to always use braces with variable names (e.g. "${var}" or "$var"):

> These are meant to be guidelines, as the topic seems too controversial for a mandatory regulation.

It's nice to see that even Google has bike-shedding arguments.

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

When breaking a pipe into two lines, I find it cleaner to end the first line with pipe instead of backslash. Then I indent the second line. Bash knows a command cannot end with pipe, therefore it's syntactically ok.

E.g.

  cmd1 |
    cmd2

  cmd1 \
    | cmd2

I'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!

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.

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

> If performance matters, use something other than shell.

I wrote a script that wrapped compiler calls to make dummy output files to debug a huge compilation. Since startup time was the most important metric, bash actually had by far the best performance.

I write long bash and perl scripts. I keep things neat and tidy most of the time. My "temporary workarounds" are still in use today, in production, so I must have written them well enough for people to understand. I see a lot of debate around preferences at the risk of becoming a funny title on n-gate. Just use whatever languages you know best. If it follows the best practices of that language, someone can port it to their preferred language.

Maybe it is just my browser, but that xml file should be renamed to .txt or have the mime type set differently. There is no formatting for me. It is just one really long line.

> Indent 2 spaces

It's interesting how quickly the 2-space indent became the new norm

    # Not this:
    if [[ "${my_var}X" = "some_stringX" ]]; then
      do_something
    fi

Original HN title had the word "Google" in it.

According to this document, Google requires Bash.

I do not use Bash. I use Almquist shell. I try to avoid using uncommon "features" or utilities.

I am not a frequent Linux user but whenever I have to use it, all of the hundreds of scripts I wrote using another OS and Almquist shell still work. They all work in Bash.

Over the years, I used this site as a reference:

https://www.in-ulm.de/~mascheck/

"One example of this is Solaris SVR4 packages which require plain Bourne shell for any scripts."

Such as?

" Indent 2 spaces. No tabs."

Oh dear, here we go....

>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 day-to-day interactive shell. But, for the love of god, write your scripts with POSIX sh.