[eropple]

I suggest you read my post and maybe let it roll around your head that I've considered my environment and the domain of my problems in a way you aren't giving me credit for. Perhaps even, with that whole mention of devops, I do something such as--crazy thought incoming--install an updated version of bash on every system I must provision, just as I do Ruby, Python, etc.?

"Decent shell script" is not a synonym for "portable shell script" and the presumption therein is what I was addressing.

[sigzero]

Exactly so. If I want PORTABLE, I write to "sh". If I want BASH, I write to BASH. The term "decent shell script" is wrong the way he uses it.

[mysidia]

Perhaps he didn't deliver the point... but BASH is not a good or safe language to write to.

Writing to '/bin/sh' is understandable due to its ubiquitousness.

Bash is a superset that is not so ubiquitous, so it doesn't have the advantage that writing to /bin/sh does.

If you don't want portable, then don't write to shell script. Write to Perl Ruby or Python, which is also safer and more secure.

[eropple]

/bin/bash is on literally every machine I ever touch. It is on every Debian machine. It is on every Ubuntu machine. It is on every OS X machine. It is on every Windows (!) machine. And there are plenty of operations that are significantly more cumbersome to write in Ruby--otherwise, sure, I would do so. Backticks are nice, but there's no `set -e` (that I am aware of) and it becomes a huge hassle to do things in a smart, error-checking way.

[stephenr]

No-one claimed Bash isn't widely distributed and installed by default.

However, unless you are patching and compiling the same version of Bash, you absolutely do not have the same version on all those machines, and that is the whole reason NOT to target Bash in shell scripts - its features are not always consistent/compatible across versions.

[lutusp]

> /bin/bash is on literally every machine I ever touch. It is on every Debian machine. It is on every Ubuntu machine. It is on every OS X machine. It is on every Windows (!) machine.

Yes. Yes. Yes. Yes. No (unless Cygwin is installed).

[eropple]

/bin/bash is on literally every machine I ever touch. Did you miss the operative phrase?

(I have init scripts for Cygwin, too, because I need Windows but life is too short for CSRSS.)

[lutusp]

> /bin/bash is on literally every machine I ever touch. Did you miss the operative phrase?

You intended that subjunctive clause to apply to all the sentences, an intent I missed. My mistake. :)

This may soon become a tempest in a teapot, as patched Bash versions are now appearing. I just patched all my machines.

[stephenr]

> "Decent shell script" is not a synonym for "portable shell script"

Only for you. For me and a lot of others I suspect, if it isn't portable it isn't worth the trouble.

If you have to re-compile a newer/older version of a shell to get the same results across machines, any potential benefits start to seem insignificant compared to the effort involved.

[eropple]

How? I already am running Chef on every machine I touch.

[stephenr]

So you have a chef recipe to download and compile the same version of bash on every platform you use?

How do you handle situations where bash is included by default?

Do you remove the package or just push your binary over the top?

If you don't remove it, what happens when a package update then replaces your binary?

How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?

[eropple]

> So you have a chef recipe to download and compile the same version of bash on every platform you use?

No, I have a chef recipe to install the newest version of bash 4 everywhere. How is an implementation detail. (I use Ubuntu packages and Homebrew, I only compile on cygwin.)

> How do you handle situations where bash is included by default? Do you remove the package or just push your binary over the top?

On OS X, the only place that's the case, I replace the binary (by using the Homebrew-compiled one).

> How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?

I've written the Chef recipe to not need regular updates. I run my Chef update stuff on a weekly basis. I can do so manually if I need to.

[stephenr]

Bash is known to have version/compatibility issues - Homebrew reports Bash 4.3, but Ubuntu only has 4.3 available for the most recent version - anything from before April will only get 4.2.

This is my whole point - targeting /bin/sh means targeting a POSIX compliant shell, which may be implemented by any number of different codebases, with a defined standard to meet. Posix mode in Bash 4.3 should be the same as Posix mode in Bash 3.9, etc. - targeting /bin/bash means targeting whatever specific bash oddities come with the version installed.

[eropple]

That's a fair point for bash ultra-power users. It doesn't really reflect on my use case. I don't exactly pull out all the stops. I use [[ ]] and set -e, which have very familiar semantics that haven't changed for a long time, and that's about it. I am very confident in my selection of "portable bash"-isms as far back as 3.2 (running 4.x on OS X has only come on recent, I added it a couple months ago).

Don't get me wrong: I could use /bin/sh. But I would have to write worse code to do it. I'll take the possibility of a bash regression over writing all my shell scripts in sh.

[SamReidHughes]

Gosh, you are so clever.