GNU bug report logs - #52873
expr unexpected syntax error

Previous Next

Full log

Message #18 received at 52873-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Martin Rixham <martin.rixham <at> equalexperts.com>
Cc: 52873-done <at> debbugs.gnu.org, Davide Brini <dave_br <at> gmx.com>
Subject: Re: bug#52873: expr unexpected syntax error
Date: Wed, 29 Dec 2021 12:57:59 -0800

On 12/29/21 12:01, Martin Rixham wrote:
> What nonsense. I want to parse source code. ')' is not an uncommon line of
> source code. It should work.

Unfortunately, you're asking for what is in general impossible. If the 
left argument of ':' could be any string, then the grammar for 'expr' 
would be ambiguous. Consider the following shell command:

expr '(' : ')'

This outputs ':' because it evaluates the parenthesized string ':'; but 
if the operands of ':' could be any strings it could also be interpreted 
as matching '(' against ')', which means it should output the same thing 
as 'expr a : b', namely '0'.

Of course this means 'expr' was poorly designed in the 1970s, but we're 
stuck with that design now (it's standardized by POSIX), portable code 
must deal with this poor design, and for compatibility reasons it's 
better for GNU expr to support the design, poor as it is.

These days there are much better ways than 'expr' to parse code. For 
example, if you want to count the number of characters in a shell 
variable v, you can use this shell command:

nv=${#v}

This works even if v=')', whereas this:

nv=$(expr "$v" : '.*')

has the bug that you mentioned, plus it's harder to read and it's less 
efficient.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.