choice of control operators in scripts

[Bernhard Fischer]

On Mon, May 12, 2008 at 11:02:22PM -0400, Paul Fox wrote:
>denys wrote:
> > On Monday 12 May 2008 23:06, Paul Fox wrote:
> > >  > > If you fell paranoid today (highly recommended),
> > >  > > add x"" to guard against less than ideal implementations of []
> > >  > > which can be confused by e.g. foo=-n :
> > >  > >
> > >  > > [ x"$foo" = x"bar" ]
> > >  > 
> > >  > I have no experience of shells that are _so_ buggy.  Do you mean this:
> > >  > 
> > >  > [ x-n = xbar ]
> > >  > 
> > >  > might confuse any non-buggy shell?
> > > 
> > > no.  he means that this:
> > >   [ "-n" = "bar" ]
> > > 
> > > might confuse a shell that interprets it as:
> > >   [ -n = bar ]
> > > 
> > > i've never seen such a shell.  i think adding the 'x' "just in
> > > case" is very ugly.
> > 
> > It's not "just in case". There are shells and [ programs
> > which are known to be buggy. Hell, not so long ago bbox's
> > one was fixed for a similar bug!
>
>i'm sure there have been lots of bugs, in lots of shells.  but if
>you start by assuming your shell is buggy, then you might as well
>give up.  there is no point in writing scripts to cater to such
>use.  who knows what other bugs there might be?

A testsuite is supposed to run in about any shell and with about any
test(1).
I've seen [ `echo one two` = "one two" ] fail because the first string
was not interpreted as one string (i.e. "`something`" to be safe).
And of course i've seen those dreaded test(1) impls that misinterpret
arbitrary strings as args (hence "x$myvariable" != "x") and some ancient
test(1) impls don't support -n and/or -z, fwiw.

Either we add some basic sanity-test as 0000.tests (or aaaa.tests, have
fun with collate) that bail out if our assumptions of sane tools are not
satisfied or write the test as robust as possible, obviously.