Re: [PATCH 6/7] syntax-check: fix violations and implement sc_prohibit_test_const_follows_var.

[Stefano Lattarini]

[adding bug-autoconf in CC]

On Tuesday 22 November 2011, Gary V wrote:
> Hi Eric,
> 
> On 22 Nov 2011, at 03:07, Eric Blake wrote:
> 
> > On 11/21/2011 07:47 AM, Gary V. Vaughan wrote:
> >> To safely use a non-literal first argument to `test', you must
> >> always prepend a literal non-`-' character, but often the second
> >> operand is a constant that doesn't begin with a `-' already, so
> >> always use `test a = "$b"' instead of noisy `test "X$b" = Xa'.
> > 
> > Not true.
> > 
> > test a = "$b"
> > 
> > is just as likely to trigger improper evaluation in buggy test(1)
> > implementations as:
> > 
> > test "$b" = a
> 
> :-o  For real?  On non-museum pieces?
>
On Solaris 10 I see this:

 $ /bin/sh -c 'b="("; test "$b" = a'; echo status = $?
 /bin/sh: test: argument expected
 status = 1

 $ /bin/sh -c 'b="!"; test "$b" = a'; echo status = $?
 /bin/sh: test: argument expected
 status = 1

And on NetBSD 5.1 I see this:

  $ /bin/sh -c 'b="("; test "$b" = a'; echo status = $?
  test: closing paren expected
  status = 2

  $ /bin/sh -c 'b="!"; test "$b" = a'; echo status = $?
  test: a: unexpected operator
  status = 2

And in fact the autconf manual says:

  Similarly, Posix says that both `test "string1" = "string2"' and
  `test "string1" != "string2"' work for any pairs of strings, but
  in practice this is not true for troublesome strings that look
  like operators or parentheses, or that begin with `-'.

(Text that should be probably be expandend to show some examples,
*and* to report the exact names and versions of the affected
shells).

> I tested a bunch of /bin/sh, bash, ksh and zsh versions that I have
> easy access to, and for all of them, the only way to upset test with
> leading hypens the first argument.
>
I couldn't do this either (for leading hypens, that is); but see the
slighlty more elaborated issues presented above.

> > If you cannot guarantee the contents of "$b", then you MUST prefix both
> > sides of the comparison with x or X.  Conversely, if you CAN guarantee
> > the contents of "$b" (for example, if you did b=$?, then you KNOW that b
> > is a numeric tring with no problematic characters), then you might as
> > well use the more idiomatic comparison of variable to constant.
> 
> I don't suppose you can point me at a shell that chokes or fails on:
> 
>    test a != -b || echo bug
> 
> ?  Or at least some reliable documentation that shows we're not dealing
> with outdated dogma here?
> 
> I'll postpone pushing this patch until we get to the bottom of the
> issue though.
> 
> Cheers,
> -- 
> Gary V. Vaughan (gary AT gnu DOT org)
> 
 
Regards,
  Stefano