Re: What shells fail to work if comparing with ?

2011-02-10 Thread Eric Blake
On 02/10/2011 11:56 AM, Dr. David Kirkby wrote:
 I know its considered bad practice to check for an empty string with
 something like:
 
 if [ $STR =  ] ; then
 
 but what shells do actually break with this, and under what conditions?

At least Solaris /bin/sh mishandles particular $STR:

$ /bin/sh -c 'test \( = '; echo $?
/bin/sh: test: argument expected
1

Do you really want to be polluting stderr if $STR happens to be (?

 
 
 I was proposing someone change a test like that to
 
 if [ x$STR =  ] ; then

Won't work.  With only two arguments, that provokes syntax errors in
most versions of test.

Did you mean:

[ -z $STR ]

or

[ ! $STR ]

If so, that still won't work, as there are some test implementations
that get order of precedence wrong for some $STR.

Did you mean:

[ x$STR = x ]

if so, then you can see why that is the exact same recipe that the
autoconf manual is adamant about recommending, since the three-argument
form with a prefix (usually x) that guarantees that the first and last
argument can't be misinterpreted as operations and cause spurious syntax
errors.

 but someone has argued against this, saying he knows of no shell where
 the former is not acceptable.

Well, then he doesn't know about Solaris /bin/sh; there are other broken
shells still in the wild, as well.

 I realise this issue is probably more of a
 problem with older shells, but can anyone give me any examples of where
 the former will break, but the latter will be ok?

Still very much a problem to be aware of with today's portable shell
programming.

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



signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf


Re: What shells fail to work if comparing with ?

2011-02-10 Thread Ralf Wildenhues
Hello David,

* Dr. David Kirkby wrote on Thu, Feb 10, 2011 at 07:56:24PM CET:
 I know its considered bad practice to check for an empty string with 
 something like:
 
 if [ $STR =  ] ; then
 
 but what shells do actually break with this, and under what conditions?

It's not shells that break.  It's these kinds of issues:
http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/13706

Cheers,
Ralf

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf


Re: What shells fail to work if comparing with ?

2011-02-10 Thread Stefano Lattarini
On Thursday 10 February 2011, Dr David wrote:
 I know its considered bad practice to check for an empty string with 
 something like:
 
 if [ $STR =  ] ; then
 
 but what shells do actually break with this, and under what conditions?

Solaris 10 /bin/sh breaks with [ $var !=  ] for some (very corner-case)
values of $var:

  $ /bin/sh -c 'var=(; [ $var !=  ]'; echo st = $?
  /bin/sh: test: argument expected
  st = 1
  $ /bin/sh -c 'var=!; [ $var !=  ]'; echo st? = $?
  /bin/sh: test: argument expected
  st = 1

With [ $var =  ], it doesn't really break, but misbehaves by printing
spurious diagnostic:

  $ /bin/sh -c 'var=!; [ $var =  ]'; echo st = $?
  /bin/sh: test: argument expected
  st = 1
  $ bin/sh -c 'var=(; [ $var !=  ]'; echo st = $?
  /bin/sh: test: argument expected
  st = 1

The exit status is correct in this cases, though.

 I was proposing someone change a test like that to
 
 if [ x$STR =  ] ; then

I guess you mean:
  if [ x$STR = x ] ; then
right?

 but someone has argued against this, saying he knows of no shell where the 
 former is not acceptable. I realise this issue is probably more of a problem 
 with older shells,

Solaris 10 /bin/sh is not really old.

 but can anyone give me any examples of where the former will 
 break, but the latter will be ok?
 

HTH,
  Stefano

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf


Re: What shells fail to work if comparing with ?

2011-02-10 Thread David Kirkby
On 10 February 2011 18:56, Dr. David Kirkby david.kir...@onetel.net wrote:
 I know its considered bad practice to check for an empty string with
 something like:

 if [ $STR =  ] ; then

 but what shells do actually break with this, and under what conditions?


 I was proposing someone change a test like that to

 if [ x$STR =  ] ; then

Oops, I meant to put

if [ x$STR =  x ] ; then

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf


Re: What shells fail to work if comparing with ?

2011-02-10 Thread Eric Blake
On 02/10/2011 12:40 PM, Ralf Wildenhues wrote:
 Hello David,
 
 * Dr. David Kirkby wrote on Thu, Feb 10, 2011 at 07:56:24PM CET:
 I know its considered bad practice to check for an empty string with 
 something like:

 if [ $STR =  ] ; then

 but what shells do actually break with this, and under what conditions?
 
 It's not shells that break.  It's these kinds of issues:
 http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/13706

Ralf pointed out a completely different point from the Solaris /bin/sh
syntax issue - that is, that in autoconf scripts, [ and ] are special to
m4, and require extra effort to use, so you are more portable using:

test x$STR = x

than you are using:

[ x$STR = x ]

so that m4 doesn't eat the [ and ].

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



signature.asc
Description: OpenPGP digital signature
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf


Re: What shells fail to work if comparing with ?

2011-02-10 Thread Bob Friesenhahn

On Thu, 10 Feb 2011, Stefano Lattarini wrote:



but someone has argued against this, saying he knows of no shell where the
former is not acceptable. I realise this issue is probably more of a problem
with older shells,


Solaris 10 /bin/sh is not really old.


I do see the issues you mention with recently-patched /bin/sh on 
Solaris 10.  However, /usr/xpg4/bin/sh passes your tests with flying 
colors on Solaris 10.  The description of /usr/xpg4/bin/sh is 
considerably different than /bin/sh:


The /usr/bin/sh utility is a  command  programming  language
 that executes commands read from a terminal or a file.

The /usr/xpg4/bin/sh utility is a standards compliant shell.
 This  utility  provides  all  the  functionality  of ksh(1),
 except in cases discussed in  ksh(1)  where  differences  in
 behavior exist.

Interestingly, on Solaris 10, /bin/sh is a link to /sbin/sh, implying 
that it is intended for purposes like system initialization scripts.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf