Hacker News Reader

Comment by ymse | Hacker News Reader

> Executables must start with #!/bin/bash

I've started using #!/usr/bin/env bash for compatibility with non-FHS distros such as NixOS.

Happy to see arrays omitted; if you find yourself in need of bash arrays you should definitely consider a proper language.

I tend to stick to POSIX shell to the extent possible, but readonly variables and [[ ]] syntactic sugar makes sense when maintainability is more important than portability.

View on HN

Those are exactly two things I don't agree.

> Executables must start with #!/bin/bash

Either they never use *BSD, or they put their bash there. Unbelievable choice.

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

I use array all the time and never used PIPESTATUS. So what?

Frankly, I find hard-coding #!/bin/bash sensible in a large corporate setting such as Google. It prevents PATH manipulation and they obviously have a uniform and controlled environment.

Bash arrays can be convenient, but at that level of complexity Python or Ruby are much easier to read and understand (and necessarily maintain).

> .. they never use *BSD ..

pretty much

(Tedious disclaimer: my opinion only, not speaking for anybody else. I'm an SRE at Google.)

We run everything on prodimage, so operating system compatibility isn't really an issue.

Realistically, any time somebody sends me a code review with a shell script in it, my first comment is going to be "Why is this a shell script? Rewrite it in a supported language."

Re: arrays -- I generally agree, but they are best solution to certain otherwise simple problems, like storing command arguments. `cmd $FLAGS` is objectively more dangerous than `cmd "${FLAGS[@]}"` due to the globbing and word-splitting issues the former exposes. In my experience, devs are more likely to opt for the former when the latter is forbidden than switch languages (because that's work).

Reply on news.ycombinator.com