Bashisms and a call for a new posix standard
Posted by xipietotec on July 14, 2007
##EDIT##
A friend of mine just advised me of the folly of this, so I retract it. Essentially it seems that *Linux* is the culprit, that when bash is invoked as /bin/sh it should not allow non-posix compliant commands, but does.
##/EDIT##
The prevalence of bash shows that mere codification of an open standard does not in itself mean that anyone will actually follow it, and in fact this might be particularly apt when it comes to open source.
While bash of course does have a posix mode, since bash is so common as the default shell, its very uncommon to use it, and its very common to use bashisms (That is, bash specific behavior that does not conform to POSIX sh). The segue in Ubuntu from bash to dash, and the numerous broken scripts that ensued is a bit of a testament to this.
In open source in particular, because the code is available, often the superior choice is readily apparent, whatever the standard might be. This can actually provide a wide impetus for open source coders to move away from the standard because of it, creating a new de-facto standard. While with a proprietary de-facto standard there is more impetus to move toward an open standard because of the unavailability of the code, and inability to make easy (or easier) transitions from one implementation to the next.
With specific regards to the shell, the particular problem with it is the ambiguity as to what /bin/sh really means. And the unique solution actually does rely in having an open standards: create a new POSIX standard to remove the ambiguity of /bin/sh.
We allready have the Shebang, and the fairly common editor encoding line afterwards which is frequently implemented in more and more editors.
Why not create a new comment line which simply defines what /bin/sh means in the context of the script? The shell can read that line before executing the script and simulate or redirect the script to that environment. Therefore, all that would be required to transition your scripts to a new default shell is to add the comment line to the script? Versions of a particular shell that predate this implementation would simply ignore it as a comment, and you could hack the script as is done now. However it certainly makes your scripts more portable among different distros which use different default environments to have this behavior.
So that is, in short, my call for a new posix standard for shell environments.
