--- Akim Demaille <[EMAIL PROTECTED]> wrote:
-8<-
> +#
> +# FIXME: Please note the following m4_require is quite wrong: if the first
> +# occurrence of AS_DIRNAME_EXPR is in a backquoted expression, the
> +# shell will be lost. We might have to introduce diversions for
> +# setting up an M4sh scr
Here is my proposal for fixing and documenting our expr problems. I'm
applying it now so that David may run the test suite and check the
issue is indeed fixed, but of course any request for modification will
be honored.
I'm happy to (hopefully) close this thread, it was getting obscure :)
Inde
I tried to summarize the thread, and here is my proposal. Comments
are welcome, suggestions are most welcome :)
`expr'
No `expr' keyword starts with `x', so use `expr x"WORD" : 'REGEX''
to keep `expr' from misinterpreting WORD.
Don't use `length', `substr', `match' and `index'
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> expr ''
Paul> It returns the empty string on both Solaris 2.5.1 sparc
Paul> (/usr/bin/expr) and Solaris 8 sparc (both /usr/bin/expr and
Paul> /usr/xpg4/bin/expr). For what it's worth, the standard requires
Paul> this behavior.
Thanks P
Akim Demaille wrote:
> [...]
>
> expr foo : 'bar\(\)'
>
> I was expecting the later to return indeed the empty string. I'll
> have to reread the whole thread, because I don't remember if someone
> showed a case where `0' is output.
>
> I can't believe that some expr would answer `0' to
>
> expr
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 29 Nov 2000 12:29:09 +0100
>
> it's not clear to me whether there is a difference between the
> empty as a literal or as the result of an evaluation.
I don't see any difference in the standard's wording. They should
be treated the same.
> could
| Akim:
Hi!
| I'm curious as to how you plan to use this information. I got the
| impression that you were suggesting to use something like:
|
| expr foo : '\(bar\)' \| a : 'a\(\)
Nope, not exactly. It is true there are two issues being debated, and
the thread is quite confusing.
The first
Akim: I'm curious as to how you plan to use this information. I got the
impression that you were suggesting to use something like:
expr foo : '\(bar\)' \| a : 'a\(\)
but beware that this behaves on different machines:
solaris$ expr foo : '\(bar\)' \| a : 'a\(\)
0
solaris$
linux$ expr foo : '\(ba
> I meant that when `:' fails, it returns `0' instead of `', so it is my
> understanding of `expr' that using \| '' at the end is enough. This
> fix is probably all we need to fix the affected expr uses.
>
> Still, David, could you confirm that \(\) properly matches the empty
> string: running
>
| > From: Akim Demaille <[EMAIL PROTECTED]>
| > Date: 10 Nov 2000 10:23:25 +0100
| >
| > But our troubles could be worse than this, since `expr' is not used
| > only in AS_DIRNAME. For instance any CVS configure contains
| >
| > ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'`
|
| Ouch
> From: Alexandre Oliva <[EMAIL PROTECTED]>
> Date: 11 Nov 2000 04:51:04 -0200
> How about:
>
> # Work around the problem that "expr 'a' : 'a\(\)'" outputs "0" in QNX.
> case $ac_option in
> *=?*) ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'` ;;
> *) ac_optarg= ;;
> esac
Yes, that'd be even
On Nov 10, 2000, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> From: Akim Demaille <[EMAIL PROTECTED]>
>> ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'`
> Ouch. Can you rewrite that as follows to work around the bug?
How about:
# Work around the problem that "expr 'a' : 'a\(\)'" outputs "0" in
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 10 Nov 2000 10:28:29 +0100
>
> | 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 leas
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 10 Nov 2000 10:23:25 +0100
>
> But our troubles could be worse than this, since `expr' is not used
> only in AS_DIRNAME. For instance any CVS configure contains
>
> ac_optarg=`expr "x$ac_option" : 'x[^=]*=\(.*\)'`
Ouch. Can you rewrite
| 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"
> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
Paul> How about if we add an AC_PROG_EXPR that searches for a working
Paul> expr and sets EXPR to its value, or to "false" if it can't find
Paul> one. Then AS_DIRNAME_EXPR can AC_REQUIRE([AC_PROG_EXPR]) and
Paul> use "$EXPR" instead of "exp
Date: Thu, 09 Nov 2000 15:24:07 -0800
From: David Morgan <[EMAIL PROTECTED]>
> 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
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
> 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 st
19 matches
Mail list logo
