Re: [PATCH] Allow == as synonym for = in test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

* 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

[LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

Powered by Linux