* Dan Muresan <danmbox@xxxxxxxxx> [2011-03-08 08:17]: > > The hard work of many Debian maintainers fixing broken shell > > scripts and pushing these changes upstream is certainly not > > The hardest (and entirely avoidable) work fell on the shoulders of the > "community" who had scripts break mysteriously without so much as a > warning from Debian/Ubuntu. People would all of a sudden receive > errors from well established packages (such as vmware) with absolutely > no clue as to what was wrong. > > > wasted time but a great service to other platforms as well by > > Wherever Linux goes, bash goes too... except for embedded busyboxy > systems, where everything is customized by hand anyway. Well you know, not the whole world revolves around Linux. And while there are pecularities, writing shell scripts using IEEE Std 1003.1-2001 as a baseline is a good starting point for achieving portability since most modern Unix or Unix-like OS come with a shell that claims to conform to it. > > > improving portability. If you want bash or ksh scripts to work > > why do you use dash? > > No sane user cares about bash / ksh / *sh in *scripts* -- but once > sh=bash became a de-facto standard, making a change swiftly and "under > the radar" was irresponsible. We are not living in an ideal world, and > I do not wish to debate worthy causes for that inexistent ideal world. /bin/sh == bash might be common among Linux distros, however in the real world it is neither a de-facto standard nor guaranteed to even give you a POSIX-shell. While bash may be available on most platforms it versions are likely to vary. And since bash tends to make backwards-incompatible changes even with minor releases it I don't find it to be the best option for writing portable scripts. > > That is a very weak argument as it applies to many such features, > > the question is whether to create precendent here and where that'll > > I actually tend to agree with this (though I still think it's a > bikeshed issue). Now that we've paid the price to port scripts to > dash, why lose the one benefit we ever had? > > Still, I wish dash would spend more effort making sure that everything > in SUSv3 works *at least as well* as it does in Bash, and less effort > in debating == vs =. I have had to abandon certain POSIX idioms that > work well in Bash because dash does not (or did not) support them. > > Note that even when an upgraded dash fixes a bug, the impact on > distributions lingers on for years: it takes a while for new distros > to incorporate the new dash, and scripts can't know if they are > running on "new" or "old" distros. So dash, the now-default /bin/sh, > should be even more proactive about bugs than a normal package. In the real world software tends to have bugs, other shells have bugs, too. Given its resources dash is relatively well- maintained, bugs reported on this list are getting addressed. -- Guido Berhoerster -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html