bin/162468: expr(1) false syntax errors
egrosbein at rdtc.ru
Fri Nov 11 19:00:25 UTC 2011
The following reply was made to PR bin/162468; it has been noted by GNATS.
From: Eugene Grosbein <egrosbein at rdtc.ru>
To: Jilles Tjoelker <jilles at stack.nl>
Cc: bug-followup at FreeBSD.org
Subject: Re: bin/162468: expr(1) false syntax errors
Date: Sat, 12 Nov 2011 01:58:55 +0700
11.11.2011 22:44, Jilles Tjoelker ÐÉÛÅÔ:
>> [expr treats any string that looks like an operator as an operator,
>> for example, expr '>' : '.*' fails]
> The current behaviour of expr is allowed by POSIX (SUSv4, XCU 4
> Utilities, expr). If the application passes '>', this is not a string
> operand but an operator, even if that results in an invalid expression.
> This is also documented in the man page.
Yes. But I have reports that that NetBSD's and Linux's expr(1)
both work as expected.
> It would be a valid extension to allow such expressions but it is not
> immediately clear how it would work. For example, should
> expr \( = \)
> compare two strings ("0") or return a single string ("=")? And should
> expr \( + \)
> return "+" or raise an error?
It would be wise to take a look at more robust expr(1) implementations
and try to keep compatibility.
> The test utility is different in that POSIX specifies how a similar
> ambiguity shall be resolved (for a limited set of cases).
> Oh, and if you want to find a string length in a shell script, why don't
> you just use
> (given that the string is in $VAR)? If you must use expr(1), do
> expr \( "x$VAR" : '.*' \) - 1
> as described in the man page.
That's just a simple test case. In fact, I need not string length
but evaluate regexp that has ()'s:
read string < file
expr -- "$string" : 'Key: \(.*\)'
Then $string starts with '>' this fails (and $string may start with '>').
I've found a workaround: expr -- "x$string" : 'xKey: \(.*\)'
But that's only workaround, not good solution.
More information about the freebsd-bugs