Hi Paul,
Paul Eggert wrote:
>
> > From: David Morgan <[EMAIL PROTECTED]>
> > Date: Thu, 09 Nov 2000 08:12:01 -0800
>
> > > | > expr 'a' : '\(b\)' && echo failure
> > > |
> > > | Gives:
> > > | 0
> > >
> > > Result is wrong, $? right.
>
> > Wrong explanation - no characters match so the output of 0 is correct
> > (At least I think so)
>
> The POSIX standard says:
>
> Usually, the matching operator shall return a string representing
> the number of characters matched ('0' on failure). Alternatively,
> if the pattern contains at least one regular expression
> subexpression "[\(...\)]", the string corresponding to "\1" shall
> be returned.
>
> This leaves it ambiguous as to what expr 'a' : '\(b\)' should return.
> One could easily argue that it should be '0'. But in practice,
> GNU/Linux and Solaris expr both return the empty string, under the
> theory that the operation is returning a string.
I hadn't realized the ambiguity.
I can test this on some other boxes and see what happens.
>
> However, autoconf's use of expr in AS_DIRNAME should be OK either way,
> so I don't see why this matters to autoconf.
>
> > > Man! Did I miss something? David, could you double check this is
> > > right? Paul, what do you think about this?
>
> Sorry, I've lost context. Why is this a problem? If expr exits with
> nonzero status, then AS_DIRNAME will fall back on sed, right?
It will use the output of the expr and then append the output of the
sed. So we'd get a 0 . or something similar.
(Ignoring the other problem I found with the sed expression - missing a -p
is what someone said)
Does that make sense?
Regards
David
