bin/162468: expr(1) false syntax errors

[Eugene Grosbein]

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
 >   ${#VAR}
 > (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.
 
 Eugene Grosbein