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 eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
