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

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

[David A. Wheeler]

From: David A. Wheeler <dwheeler@dwheeler.com>

The following patch adds support for "==" as a synonym for "=" (is-string-equal) in test, including the documentation and comment changes to note it.

Why add this?
* Many current shell scripts use "==" instead of "=" to determine if strings are equal (as reported by https://wiki.ubuntu.com/DashAsBinSh and other places).  Bash, ksh, and probably other shells already support this, which is why its use is so common.
* Using "==" makes it slightly clearer that this is an equality test and not an assignment (since "=" is used elsewhere in shell for assignment).  Note that this is consistent with C, C++, and many other languages.
* A trivial amount of code is needed to implement it.

This isn't required by POSIX, but "test" in dash already supports tests not in POSIX.  I think it'd be useful to add one that's already in common use.

Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>

diff --git a/src/bltin/test.1 b/src/bltin/test.1
index 42435fb..56f8163 100644
--- a/src/bltin/test.1
+++ b/src/bltin/test.1
@@ -193,6 +193,12 @@ True if the strings
 and
 .Ar \&s\&2
 are identical.
+.It Ar \&s\&1 Cm \&=\&= Ar \&s\&2
+True if the strings
+.Ar \&s\&1
+and
+.Ar \&s\&2
+are identical (this is a synonym for \&=).
 .It Ar \&s\&1 Cm \&!= Ar \&s\&2
 True if the strings
 .Ar \&s\&1
diff --git a/src/bltin/test.c b/src/bltin/test.c
index 7888f38..5a581ed 100644
--- a/src/bltin/test.c
+++ b/src/bltin/test.c
@@ -31,7 +31,7 @@
        unary-operator ::= "-r"|"-w"|"-x"|"-f"|"-d"|"-c"|"-b"|"-p"|
                "-u"|"-g"|"-k"|"-s"|"-t"|"-z"|"-n"|"-o"|"-O"|"-G"|"-L"|"-S";

-       binary-operator ::= "="|"!="|"-eq"|"-ne"|"-ge"|"-gt"|"-le"|"-lt"|
+       binary-operator ::= "="|"=="|"!="|"-eq"|"-ne"|"-ge"|"-gt"|"-le"|"-lt"|
                        "-nt"|"-ot"|"-ef";
        operand ::= <any legal UNIX file name>
 */
@@ -113,6 +113,7 @@ static struct t_op {
        {"-L",  FILSYM, UNOP},
        {"-S",  FILSOCK,UNOP},
        {"=",   STREQ,  BINOP},
+       {"==",  STREQ,  BINOP},
        {"!=",  STRNE,  BINOP},
        {"<",   STRLT,  BINOP},
        {">",   STRGT,  BINOP},

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

[Jonathan Nieder]

Hi David,

David A. Wheeler wrote:

> This isn't required by POSIX, but "test" in dash already supports
> tests not in POSIX.  I think it'd be useful to add one that's
> already in common use.

Thanks for writing this.

Generally speaking, dash tends to support features that ash and older
versions of dash supported (to avoid breaking backward compatibility)
and features accepted for POSIX.  Has the Austin Group made a decision
on whether this syntax is going to be supported?  I'd be happier about
it once the Austin Group has accepted it[1].

But it's nice to see the patch is simple.

Just my two cents,
Jonathan

[1] http://austingroupbugs.net/view.php?id=375

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

[David A. Wheeler]

Jonathan Nieder:
> Has the Austin Group made a decision
> on whether this syntax is going to be supported?

I don't think a decision has been formally made.  Most of the email discussion has been about possibly adding "<" and ">" to the spec, which are not in the current POSIX spec but are already implemented in dash.  The last comment posted on mantis about this extension to POSIX was positive; eblake (manager) said, "adding the other four operators (==, -ot, -nt, -ef) make[s] sense" [http://austingroupbugs.net/view.php?id=375].

> dash tends to support features that ash and older
> versions of dash supported (to avoid breaking backward compatibility)

Busybox's ash *already* supports "==", so I think that's *also* an argument for adding "==".  After all, adding "==" would improve compatibility between busybox ash and dash, and its effect on space and speed is miniscule.  I understand that dash wants to be "lean and mean", but busybox does too, and even busybox supports "==". 

I think it's reasonably likely that "==" will be added to the POSIX spec, but that's not up to me.  Even if this syntax isn't added to the official standard, I still think it'd make sense to support "==".  It's already implemented in a number of shells, including bash, busybox ash, and ksh.  More importantly, a lot of extant shell scripts use it; many scripts won't work on dash because dash doesn't include "==".

--- David A. Wheeler

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

[Guido Berhoerster]

* David A. Wheeler <dwheeler@dwheeler.com> [2011-03-07 02:12]:
> Jonathan Nieder:
> > Has the Austin Group made a decision
> > on whether this syntax is going to be supported?
> 
> I don't think a decision has been formally made.  Most of the email discussion has been about possibly adding "<" and ">" to the spec, which are not in the current POSIX spec but are already implemented in dash.  The last comment posted on mantis about this extension to POSIX was positive; eblake (manager) said, "adding the other four operators (==, -ot, -nt, -ef) make[s] sense" [http://austingroupbugs.net/view.php?id=375].
> 
> > dash tends to support features that ash and older
> > versions of dash supported (to avoid breaking backward compatibility)
> 
> Busybox's ash *already* supports "==", so I think that's *also* an argument for adding "==".  After all, adding "==" would improve compatibility between busybox ash and dash, and its effect on space and speed is miniscule.  I understand that dash wants to be "lean and mean", but busybox does too, and even busybox supports "==". 
> 
> I think it's reasonably likely that "==" will be added to the POSIX spec, but that's not up to me.  Even if this syntax isn't added to the official standard, I still think it'd make sense to support "==".  It's already implemented in a number of shells, including bash, busybox ash, and ksh.  More importantly, a lot of extant shell scripts use it; many scripts won't work on dash because dash doesn't include "==".

By that argument pretty much every (mis)feature of bash can be
included into dash because people keep writing scripts assuming
/bin/sh == bash which of course will not work on dash.
I consider dash's orientation towards POSIX/SUS compliance and
lack of support for many extensions a feature, it makes it easy
to extend with later POSIX features without breaking backwards
compatibility and allows one to easily spot bashisms in /bin/sh
scripts. Hence I don't think it is a good idea to add this to
dash before it is being standardized.
BTW, dash's test builtin already supports the -ot, -nt, and -ef
operators, unfortunately -ot and -nt behavior differs from all
other implementations [1].

[1] http://www.mail-archive.com/dash@vger.kernel.org/msg00206.html
-- 
Guido Berhoerster

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

[David A. Wheeler]

Jonathan Nieder:
> > > dash tends to support features that ash and older
> > > versions of dash supported (to avoid breaking backward compatibility)

I said:
> > Busybox's ash *already* supports "==", so I think that's *also*
> > an argument for adding "==".
> >  After all, adding "==" would improve compatibility between
> > busybox ash and dash, and its effect on space and speed is miniscule.

Guido Berhoerster:
> By that argument pretty much every (mis)feature of bash...

But is "==" a misfeature? I don't think so.

>  can be
> included into dash because people keep writing scripts assuming
> /bin/sh == bash which of course will not work on dash.

That's not the argument I made there; I wasn't talking about bash.
Jonathan Nieder said that dash "tends to support features [of] ash".
Busybox ash is *also* an ash, as shown in this family tree:
  http://www.in-ulm.de/~mascheck/various/ash/
Busybox ash is an *ash*, it's not *bash*, and dash is lacking a feature
for compatibility with another *ash*.

> I consider dash's orientation towards POSIX/SUS compliance and
> lack of support for many extensions a feature...
> Hence I don't think it is a good idea to add this to
> dash before it is being standardized.

Most comments about "==" in the POSIX/SUS group have been positive.  There was only one negative comment that I remember, and it primarily noted that == is not in dash and FreeBSD.  If the POSIX group will never add new capabilities until dash adds them, and dash will never add anything until POSIX adds them, we have a deadlock :-).

> and allows one to easily spot bashisms in /bin/sh scripts.

This is no longer a "bashism", as it's also in ksh and busybox ash at least, and probably others.

> it makes it easy
> to extend with later POSIX features without breaking backwards
> compatibility

Given how many shells already implement "==" as "=", it's highly improbable that it would ever have a different semantic.  It's hard to make the semantics clearer, in fact: "synonym for =".

> [I consider the] lack of support for many extensions a feature,

BusyBox doesn't want lots of options either, yet even their ash supports "==". The page <http://www.busybox.net/about.html> says:
"BusyBox combines tiny versions of many common UNIX utilities into a single small executable... The utilities in BusyBox generally have fewer options [but] provide the expected functionality...  BusyBox has been written with size-optimization and limited resources in mind."

There's value in "lean and mean", but this is a few bytes we're talking about, for a feature that is already widely used.

--- David A. Wheeler

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

[Guido Berhoerster]

* David A. Wheeler <dwheeler@dwheeler.com> [2011-03-07 15:56]:
> Jonathan Nieder:
> > > > dash tends to support features that ash and older
> > > > versions of dash supported (to avoid breaking backward compatibility)
> 
> I said:
> > > Busybox's ash *already* supports "==", so I think that's *also*
> > > an argument for adding "==".
> > >  After all, adding "==" would improve compatibility between
> > > busybox ash and dash, and its effect on space and speed is miniscule.
> 
> Guido Berhoerster:
> > By that argument pretty much every (mis)feature of bash...
> 
> But is "==" a misfeature? I don't think so.

Mind the braces, also my argument was directed more generally
towards adding further non-SUS/POSIX extensions to dash.

> >  can be
> > included into dash because people keep writing scripts assuming
> > /bin/sh == bash which of course will not work on dash.
> 
> That's not the argument I made there; I wasn't talking about bash.
> Jonathan Nieder said that dash "tends to support features [of] ash".
> Busybox ash is *also* an ash, as shown in this family tree:
>   http://www.in-ulm.de/~mascheck/various/ash/
> Busybox ash is an *ash*, it's not *bash*, and dash is lacking a feature
> for compatibility with another *ash*.

There are many variants of ash and some of them are already
incompatible with each other (e.g. the -nt/-ot test operators
that I pointed out in my previous reply). Why should we care
about busybox ash anyway it seems to be the only ash descendant
to implement that, the FreeBSD/NetBSD ones don't.

> 
> > I consider dash's orientation towards POSIX/SUS compliance and
> > lack of support for many extensions a feature...
> > Hence I don't think it is a good idea to add this to
> > dash before it is being standardized.
> 
> Most comments about "==" in the POSIX/SUS group have been positive.  There was only one negative comment that I remember, and it primarily noted that == is not in dash and FreeBSD.  If the POSIX group will never add new capabilities until dash adds them, and dash will never add anything until POSIX adds them, we have a deadlock :-).

I don't think the discussions taking place under the umbrella at
the Austing group would give that much weight to dash as == is a
feature addition of ksh and later bash which are probably in more
widespread use than dash. Besides, if it really was to be part of
an upcoming standard it should of course be added as dash aims
to be a "POSIX-compliant implementation" of the shell.
Note that there are also at least two different "test" variants
used with ash, there is a combined test/expr builtin and
standalone version of the test command included in the ash
sources from 1989 and there are various versions derived from the
pdksh test command which was imported by NetBSD and has spread
from there to FreeBSD and the first the ash Linux port in 1993.

> 
> > and allows one to easily spot bashisms in /bin/sh scripts.
> 
> This is no longer a "bashism", as it's also in ksh and busybox ash at least, and probably others.

Sure, but so are many other features of the test builtins that
come with these shells.
I was generically referring to "bashisms" since the ignorance
in using such non-standard features and constructs while
requesting the /bin/sh interpreter seems to be a particularly
common bad habit among bash users coming from the linux camp
where it often is a symlink to bash (Debian and its derivatives
being the notable exception here). (I'm also not implying that
one should expect /bin/sh to be the POSIX shell.)

> 
> > it makes it easy
> > to extend with later POSIX features without breaking backwards
> > compatibility
> 
> Given how many shells already implement "==" as "=", it's highly improbable that it would ever have a different semantic.  It's hard to make the semantics clearer, in fact: "synonym for =".

In this case that might be correct, however...

> 
> > [I consider the] lack of support for many extensions a feature,
> 
> BusyBox doesn't want lots of options either, yet even their ash supports "==". The page <http://www.busybox.net/about.html> says:
> "BusyBox combines tiny versions of many common UNIX utilities into a single small executable... The utilities in BusyBox generally have fewer options [but] provide the expected functionality...  BusyBox has been written with size-optimization and limited resources in mind."
> 
> There's value in "lean and mean", but this is a few bytes we're talking about, for a feature that is already widely used.

... I was trying to make a more generic argument, in particular
where does one draw the line? What will be added next? There are
surely a lot of scripts that break because they use "[[", and
it's also widely implemented and useful since it doesn't do
pathname expansion and word splitting, that applies to the "<"
and ">" test operators as well etc. etc.

Currently, from what I can see the criteria for including
features in dash seems to have been compliance with POSIX/SUS
specification while simultaneously maintaining backwards
compatibility with custom extensions and I think that has worked
well.
-- 
Guido Berhoerster

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

[Dan Muresan]

It's amazing to see how much energy is devoted to a "bike shed issue"
(like ==) when the opportunity arises, and how little responses an
actual bug report tends to see here.

It's also great to see dash now gradually making a U-turn, after the
crusade against "bashisms" has broken so many scripts and wasted so
many man-hours for Debian / Ubuntu users.

Keep on rocking, guys!

On Mon, Mar 7, 2011 at 7:18 PM, Guido Berhoerster
<guido+kernel.org@berhoerster.name> wrote:
> * David A. Wheeler <dwheeler@dwheeler.com> [2011-03-07 15:56]:
>> Jonathan Nieder:
>> > > > dash tends to support features that ash and older
>> > > > versions of dash supported (to avoid breaking backward compatibility)
>>
>> I said:
>> > > Busybox's ash *already* supports "==", so I think that's *also*
>> > > an argument for adding "==".
>> > >  After all, adding "==" would improve compatibility between
>> > > busybox ash and dash, and its effect on space and speed is miniscule.
>>
>> Guido Berhoerster:
>> > By that argument pretty much every (mis)feature of bash...
>>
>> But is "==" a misfeature? I don't think so.
>
> Mind the braces, also my argument was directed more generally
> towards adding further non-SUS/POSIX extensions to dash.
>
>> >  can be
>> > included into dash because people keep writing scripts assuming
>> > /bin/sh == bash which of course will not work on dash.
>>
>> That's not the argument I made there; I wasn't talking about bash.
>> Jonathan Nieder said that dash "tends to support features [of] ash".
>> Busybox ash is *also* an ash, as shown in this family tree:
>>   http://www.in-ulm.de/~mascheck/various/ash/
>> Busybox ash is an *ash*, it's not *bash*, and dash is lacking a feature
>> for compatibility with another *ash*.
>
> There are many variants of ash and some of them are already
> incompatible with each other (e.g. the -nt/-ot test operators
> that I pointed out in my previous reply). Why should we care
> about busybox ash anyway it seems to be the only ash descendant
> to implement that, the FreeBSD/NetBSD ones don't.
>
>>
>> > I consider dash's orientation towards POSIX/SUS compliance and
>> > lack of support for many extensions a feature...
>> > Hence I don't think it is a good idea to add this to
>> > dash before it is being standardized.
>>
>> Most comments about "==" in the POSIX/SUS group have been positive.  There was only one negative comment that I remember, and it primarily noted that == is not in dash and FreeBSD.  If the POSIX group will never add new capabilities until dash adds them, and dash will never add anything until POSIX adds them, we have a deadlock :-).
>
> I don't think the discussions taking place under the umbrella at
> the Austing group would give that much weight to dash as == is a
> feature addition of ksh and later bash which are probably in more
> widespread use than dash. Besides, if it really was to be part of
> an upcoming standard it should of course be added as dash aims
> to be a "POSIX-compliant implementation" of the shell.
> Note that there are also at least two different "test" variants
> used with ash, there is a combined test/expr builtin and
> standalone version of the test command included in the ash
> sources from 1989 and there are various versions derived from the
> pdksh test command which was imported by NetBSD and has spread
> from there to FreeBSD and the first the ash Linux port in 1993.
>
>>
>> > and allows one to easily spot bashisms in /bin/sh scripts.
>>
>> This is no longer a "bashism", as it's also in ksh and busybox ash at least, and probably others.
>
> Sure, but so are many other features of the test builtins that
> come with these shells.
> I was generically referring to "bashisms" since the ignorance
> in using such non-standard features and constructs while
> requesting the /bin/sh interpreter seems to be a particularly
> common bad habit among bash users coming from the linux camp
> where it often is a symlink to bash (Debian and its derivatives
> being the notable exception here). (I'm also not implying that
> one should expect /bin/sh to be the POSIX shell.)
>
>>
>> > it makes it easy
>> > to extend with later POSIX features without breaking backwards
>> > compatibility
>>
>> Given how many shells already implement "==" as "=", it's highly improbable that it would ever have a different semantic.  It's hard to make the semantics clearer, in fact: "synonym for =".
>
> In this case that might be correct, however...
>
>>
>> > [I consider the] lack of support for many extensions a feature,
>>
>> BusyBox doesn't want lots of options either, yet even their ash supports "==". The page <http://www.busybox.net/about.html> says:
>> "BusyBox combines tiny versions of many common UNIX utilities into a single small executable... The utilities in BusyBox generally have fewer options [but] provide the expected functionality...  BusyBox has been written with size-optimization and limited resources in mind."
>>
>> There's value in "lean and mean", but this is a few bytes we're talking about, for a feature that is already widely used.
>
> ... I was trying to make a more generic argument, in particular
> where does one draw the line? What will be added next? There are
> surely a lot of scripts that break because they use "[[", and
> it's also widely implemented and useful since it doesn't do
> pathname expansion and word splitting, that applies to the "<"
> and ">" test operators as well etc. etc.
>
> Currently, from what I can see the criteria for including
> features in dash seems to have been compliance with POSIX/SUS
> specification while simultaneously maintaining backwards
> compatibility with custom extensions and I think that has worked
> well.
> --
> Guido Berhoerster
> --
> To unsubscribe from this list: send the line "unsubscribe dash" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Dan Muresan
http://alumnus.caltech.edu/~muresan/

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

[Jonathan Nieder]

Hi David,

David A. Wheeler wrote:

> But is "==" a misfeature? I don't think so.

For what it's worth, I have no strong objections to "==" (though no
great excitement about it either).  I was only taking the opportunity
to explain the possibly mysterious-seeming current feature set.

> Jonathan Nieder said that dash "tends to support features [of] ash".
> Busybox ash is *also* an ash, as shown in this family tree:

I suppose you misunderstood.  dash decends from the original ash.
Sometimes features disappear --- then they tend to be gone for good.
Backward compatibility of the kind I was describing is meant to
facilitate upgrades.

> There was only one negative comment that I remember, and it
> primarily noted that == is not in dash and FreeBSD.

That comment was by a contributor to both of those projects, and I
seem to remember it noting _why_ "==" is not in dash and FreeBSD
yet.

> If the POSIX
> group will never add new capabilities until dash adds them,

I don't think that's the case.  If your goal is to advance this in
POSIX, I don't think implementing in dash is a necessary prerequisite.

> There's value in "lean and mean", but this is a few bytes we're
> talking about, for a feature that is already widely used.

Anyway, I suppose Herbert can decide whether it's worth applying
the patch, now that the explaining has been taken care of.

My (personal) advice is to wait.  Presumably soon we will know whether
== is to be part of the "test" builtin in POSIX or is going to be
allowed in "[[" only.

Kind regards,
Jonathan

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

[David A. Wheeler]

Jonathan Nieder:
> Presumably soon we will know whether
> == is to be part of the "test" builtin in POSIX or is going to be
> allowed in "[[" only.

I presume you mean "required", not "allowed".  POSIX already allows "=="  (several POSIX shells currently implement it), it's just not *required* in test/[.

Which means there's no need to wait; "==" can be added as an aid to users, whether or not it's in POSIX (yet).

It's not clear to me that "[[" will be added.  That was proposed early on as an idea, but to my knowledge one was proposed any specific text to actually *do* that, and it was rejected last time.  On the other hand, "==" has already been proposed, and most of the discussion seemed to think it reasonable.

Dan Muresan:
> ...the crusade against "bashisms" has broken so many scripts and wasted so
> many man-hours for Debian / Ubuntu users.

Right.  Many existing scripts depend on "==", not "=", and its implementation is trivial.

--- David A. Wheeler

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On 03/07/2011 05:05 PM, Guido Berhoerster wrote:
> * David A. Wheeler <dwheeler@dwheeler.com> [2011-03-08 00:03]:
>> Dan Muresan:
>>> ...the crusade against "bashisms" has broken so many scripts and wasted so
>>> many man-hours for Debian / Ubuntu users.
> 
> The hard work of many Debian maintainers fixing broken shell
> scripts and pushing these changes upstream is certainly not
> wasted time but a great service to other platforms as well by
> improving portability. If you want bash or ksh scripts to work
> why do you use dash?
> 
>> Right.  Many existing scripts depend on "==", not "=", and its implementation is trivial.
> 
> 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
> go.

Personally, I _don't_ want to see this in dash _until_ the Austin Group
makes their ruling on the pending discussion item of whether the next
version of POSIX will be requiring support for '=='.  But if the Austin
Group ultimately requires it, then we've proven that it's very easy to
add to dash at that time.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

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

[Guido Berhoerster]

* David A. Wheeler <dwheeler@dwheeler.com> [2011-03-08 00:03]:
> Dan Muresan:
> > ...the crusade against "bashisms" has broken so many scripts and wasted so
> > many man-hours for Debian / Ubuntu users.

The hard work of many Debian maintainers fixing broken shell
scripts and pushing these changes upstream is certainly not
wasted time but a great service to other platforms as well by
improving portability. If you want bash or ksh scripts to work
why do you use dash?

> Right.  Many existing scripts depend on "==", not "=", and its implementation is trivial.

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

-- 
Guido Berhoerster

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

[Dan Muresan]

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

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

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

-- Dan

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

[Paul Smith]

On Tue, 2011-03-08 at 09:17 +0200, Dan Muresan wrote:
> Wherever Linux goes, bash goes too... except for embedded busyboxy
> systems, where everything is customized by hand anyway.

No one ever said you couldn't write shell scripts in bash rather than in
sh, even on Ubuntu.  You just have to use #!/bin/bash at the top, not
#!/bin/sh.  Truth in scripting!


On the other hand, I think you're underestimating the types of software
that would go on an embedded busybox system: I run PXE-booted systems on
blades that have 8+ cores and 24+G RAM, and 10gig ethernet interfaces.
And they use busybox (because who wants to waste ramdisk space on a full
GNU toolset?  I NEED that memory for other things).  And they use a
bunch of other tools that I would dearly love to not have to "customize
by hand".

It's one of the banes of my (professional) life, all the scripts out
there for tools I want to install on my blades, written by people who
think if it runs on Red Hat it's done and that sh == bash (... and who
think they can write their own makefiles/configure environments that are
as good as or better than the GNU autotools--but that's a topic for
another day).


I personally am very grateful to Ubuntu for taking the high road here
and forcing some sanity and consideration back into the scripting
culture.  Little by little things ARE getting better.

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

[Dan Muresan]

> No one ever said you couldn't write shell scripts in bash rather than in
> sh, even on Ubuntu.  You just have to use #!/bin/bash at the top, not
> #!/bin/sh.  Truth in scripting!

Please, not *that* red herring again... You know very well that the
existing packages that broke were the problem, not the scripts yet to
be written.

Maybe I've made too many points, so let me summarize:

1) changing from sh=bash to sh=dash in Ubuntu was done without due
publicity for such a monumental upheaval. This should not have been
buried in some bash / dash NEWS.gz, nor in some release notes. This
should have been included in ALL CAPS in all public announcements, on
all forums and above all download links (I'm exaggerating but you get
the point)

2) Before the update, there should have been a campaign promoting the
checkbashisms tool

3) I personally don't think dash was quite mature enough to be the
default shell when the change was made. Maybe it's getting there
today.

4) Now that everyone has paid the large price of a poorly prepared
switch-over, I don't want dash to become more tolerant of non-POSIX
idioms. The one benefit we have from dash is that it forces POSIX
compliance.

> blades that have 8+ cores and 24+G RAM, and 10gig ethernet interfaces.

Maybe you're not in the best position to argue in this case :) I have
worked before with a few megs of RAM (and even with sub-1M DSP OSs,
but that's different).

> I personally am very grateful to Ubuntu for taking the high road here
> and forcing some sanity and consideration back into the scripting

I believe you. However, many thousands of users were *not* grateful,
and I don't see why the preferences of a minority of developers in
various niches should over-rule the necessities of a majority of
desktop users.

(Actually, we all know why stuff like this happens: Debian is not
market-driven, so users' necessities, or their poor substitute --
money -- do not directly impact its direction)

-- Dan

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

[Guido Berhoerster]

* Dan Muresan <danmbox@gmail.com> [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

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

[Dan Muresan]

> Well you know, not the whole world revolves around Linux.

Indeed -- the market "revolves" around Windows. The world of the free
desktops *does* revolve around Linux. And yes, there are others, which
I have used in the past myself (all the BSDs). Any responsible action
should take into account the demographics of the user base, not the
fondness for certain niches.

> 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

Personally I have always strived to do so...

> /bin/sh == bash might be common among Linux distros, however in
> the real world it is neither a de-facto standard nor guaranteed

I know this. As much as you might enjoy it, you're preaching to the
choir :) I was **only** arguing that the Debian / Ubuntu transition to
dash was premature (for both Debian and dash) and improperly handled.

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

Eh, not my 2 bugs. One was unanswered by Ubuntu, the other by this
very mailing list. I've since encountered several other good bug
candidates, but chose to rewrite my scripts and work around errors
without digging deeper. What can one do? Even if dash fixes something
today, it'll be several years before one can be sure that the old
version is flushed out of 90% of the desktops...

Now, when you are the default Debian shell, I think the "given its
resources" argument should never, ever be opened. Otherwise one would
be tempted to ask whether dash is suitable for its role...


-- Dan