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