[stephenr]

I guess it comes down to how you interpret things.

I specifically said any decent shell script. My logic is that if it is not using "sh", but instead relying on bash (or any other specific shell really), it's not a decent shell script.

If I were to amend the sentence to make the meaning clearer, I would still not use "should be", I would use "must be".

[eropple]

You're overreaching. I write scripts against bash, not sh, because it's a better scripting language for what I need. It's more readable and its constructs are easier (for me) to follow. I don't care about POSIX-compatibility when bash can be installed literally anywhere. It's a dependency for the devops stuff that I run and maintain, much like Ruby is a dependency and all the gems in my Gemfile.

It's a considered decision, not a sign of "indecency".

[stephenr]

I suggest you read the accepted answer at http://stackoverflow.com/questions/19428418/what-is-the-use-... for a brief look at why portable shell scripts are a better solution than bash specific scripts.

[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]

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

[yen223]

If you can confidently assert that every shell script your system runs is "decent", then you'll have no problem. The thing is, very few of us can confidently make that assertion.

[stephenr]

That all depends where your shell scripts come from.

In my experience most of the shell scripts provided by packages for debian, do use /bin/sh.

A quick check of .sh files on a couple of squeeze/wheezy installs showed that the vast majority of shell scripts using Bash come from node modules, which quite frankly is not surprising.