NetBSD Problem Report #10995

Received: (qmail 26396 invoked from network); 12 Sep 2000 01:40:07 -0000
Message-Id: <200009120140.e8C1e6g24932@fifty.cs.ubc.ca>
Date: Mon, 11 Sep 2000 18:40:06 -0700 (PDT)
From: Brian de Alwis <bsd@fifty.cs.ubc.ca>
Reply-To: bsd@fifty.cs.ubc.ca
To: gnats-bugs@gnats.netbsd.org
Subject: expr(1) barfs on regexp
X-Send-Pr-Version: 3.95

>Number:         10995
>Category:       bin
>Synopsis:       expr(1) barfs on regexp
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jdolecek
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 12 01:41:00 +0000 2000
>Closed-Date:    Tue Sep 19 17:22:09 +0000 2000
>Last-Modified:  Tue Sep 19 17:22:09 +0000 2000
>Originator:     Brian de Alwis
>Release:        NetBSD 1.5_ALPHA2
>Organization:
Dept of CS, University of British Columbia
>Environment:
	NetBSD 1.5_ALPHA2 from ftp.NetBSD.org; i386
System: NetBSD fifty 1.5_ALPHA2 NetBSD 1.5_ALPHA2 (GENERIC) #2: Mon Aug 21 19:17:53 MEST 2000 fvdl@sushi:/work/trees/netbsd-1-5/sys/arch/i386/compile/GENERIC i386


>Description:
	expr(1) barfs on a seemingly valid regexp, complaining about
	a syntax error. The Solaris expr(1) complains similarly, though
	linux's expr(1) does not. This was found in Sun's JDK 1.2.2 for
	Linux's scripts.
>How-To-Repeat:
	$ expr f : /
	expr: syntax error
	$
>Fix:

>Release-Note:
>Audit-Trail:

From: christos@zoulas.com (Christos Zoulas)
To: bsd@fifty.cs.ubc.ca, gnats-admin@netbsd.org, gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: bin/10995: expr(1) barfs on regexp
Date: Mon, 11 Sep 2000 22:11:06 -0400

 On Sep 11,  6:40pm, bsd@fifty.cs.ubc.ca (Brian de Alwis) wrote:
 -- Subject: bin/10995: expr(1) barfs on regexp

 This is the correct behavior. It thinks it is the divide operator.
 Only GNU expr works, all the rest do this.

 christos

 | >Description:
 | 	expr(1) barfs on a seemingly valid regexp, complaining about
 | 	a syntax error. The Solaris expr(1) complains similarly, though
 | 	linux's expr(1) does not. This was found in Sun's JDK 1.2.2 for
 | 	Linux's scripts.
 | >How-To-Repeat:
 | 	$ expr f : /
 | 	expr: syntax error
 | 	$
 | >Fix:
 | 
 | >Release-Note:
 | >Audit-Trail:
 | >Unformatted:
 -- End of excerpt from Brian de Alwis



From: James Chacon <jchacon@genuity.net>
To: bsd@fifty.cs.ubc.ca
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10995: expr(1) barfs on regexp
Date: Tue, 12 Sep 2000 02:32:52 -0400 (EDT)

 Rather simple fix. When a MATCH occurs eval5 calls nexttoken to get the
 right hand side expression. 

 The problem is that it'll always tokenize before it'll stringify and you don't
 want that when you're in MATCH (let regcomp deal with the string). 

 Once you're in the MATCH state you simply want the right hand side 
 stringified. Check and see, = % and other tokens all give the same behavior.

 This code is disgusting with globals all over but the good news is while 
 you're in nexttoken you know the current state so the following 1 liner
 fixes it:

 cvs diff expr.c 
 Index: expr.c
 ===================================================================
 RCS file: /cvsroot/basesrc/bin/expr/expr.c,v
 retrieving revision 1.12
 diff -u -r1.12 expr.c
 --- expr.c      2000/01/14 07:14:41     1.12
 +++ expr.c      2000/09/12 06:29:22
 @@ -201,7 +201,7 @@
         }
         av++;

 -       if (p[0] != '\0') {
 +       if ((p[0] != '\0') && (token != MATCH)) {
                 if (p[1] == '\0') {
                         const char     *x = "|&=<>+-*/%:()";
                         char           *i;      /* index */

 James

 >
 >
 >>Number:         10995
 >>Category:       bin
 >>Synopsis:       expr(1) barfs on regexp
 >>Confidential:   no
 >>Severity:       non-critical
 >>Priority:       low
 >>Responsible:    bin-bug-people
 >>State:          open
 >>Class:          sw-bug
 >>Submitter-Id:   net
 >>Arrival-Date:   Mon Sep 11 18:41:00 PDT 2000
 >>Closed-Date:
 >>Last-Modified:
 >>Originator:     Brian de Alwis
 >>Release:        NetBSD 1.5_ALPHA2
 >>Organization:
 >Dept of CS, University of British Columbia
 >>Environment:
 >	NetBSD 1.5_ALPHA2 from ftp.NetBSD.org; i386
 >System: NetBSD fifty 1.5_ALPHA2 NetBSD 1.5_ALPHA2 (GENERIC) #2: Mon Aug 21 19:17:53 MEST 2000 fvdl@sushi:/work/trees/netbsd-1-5/sys/arch/i386/compile/GENERIC i386
 >
 >
 >>Description:
 >	expr(1) barfs on a seemingly valid regexp, complaining about
 >	a syntax error. The Solaris expr(1) complains similarly, though
 >	linux's expr(1) does not. This was found in Sun's JDK 1.2.2 for
 >	Linux's scripts.
 >>How-To-Repeat:
 >	$ expr f : /
 >	expr: syntax error
 >	$
 >>Fix:
 >
 >>Release-Note:
 >>Audit-Trail:
 >>Unformatted:
 >
 >
 >
 >


From: gabriel rosenkoetter <gr@eclipsed.net>
To: Brian de Alwis <bsd@fifty.cs.ubc.ca>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10995: expr(1) barfs on regexp
Date: Tue, 12 Sep 2000 13:59:34 -0400

 On Mon, Sep 11, 2000 at 06:40:06PM -0700, Brian de Alwis wrote:
 > >Description:
 > 	expr(1) barfs on a seemingly valid regexp, complaining about
 > 	a syntax error. The Solaris expr(1) complains similarly, though
 > 	linux's expr(1) does not. This was found in Sun's JDK 1.2.2 for
 > 	Linux's scripts.
 > >How-To-Repeat:
 > 	$ expr f : /
 > 	expr: syntax error
 > 	$

 That's not a valid regex, and Linux is wrong to accept it.

 expr f : // works properly on Solaris and NetBSD.

 Erm, guess that's all just IMHO. But if you didn't close your regular
 expression properly, you don't deserve results.

 :^>

        ~ g r @ eclipsed.net

From: Brian de Alwis <bsd@cs.ubc.ca>
To: gabriel rosenkoetter <gr@eclipsed.net>
Cc: Brian de Alwis <bsd@fifty.cs.ubc.ca>, gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10995: expr(1) barfs on regexp
Date: Tue, 12 Sep 2000 15:40:38 -0700 (PDT)

 > That's not a valid regex, and Linux is wrong to accept it.

 Um, why isn't it valid? The man page itself shows the following example:

     expr $a : '.*'

 expr(1) doesn't specify a need for a delimiter. Besides, `/' isn't a
 special regexp character. What am I missing?

 -- 
 "Maybe this world is another planet's Hell." - Aldous Huxley


From: gabriel rosenkoetter <gr@eclipsed.net>
To: Brian de Alwis <bsd@cs.ubc.ca>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/10995: expr(1) barfs on regexp
Date: Tue, 12 Sep 2000 19:20:26 -0400

 On Tue, Sep 12, 2000 at 03:40:38PM -0700, Brian de Alwis wrote:
 > Um, why isn't it valid? The man page itself shows the following example:
 > 
 >     expr $a : '.*'
 > 
 > expr(1) doesn't specify a need for a delimiter. Besides, `/' isn't a
 > special regexp character. What am I missing?

 Hrm.

 Looks like I was a bit confused.

 By my logic, expr j : /j/ should return 1, but it doesn't. So expr has
 a completely weird definition of how a regular expression should be
 defined (as compared with ed, ex, etcetera). I didn't expect it was
 actually trying to match the string after the : literally, but rather
 as if it were a regular expression... but it seems to do regular
 expression character expansion on a string, disregarding delimitation.

 Based on that, I agree with what you said to begin with. expr j : /
 should return 0, not an error.

 Sorry for being ornery. :^>

        ~ g r @ eclipsed.net
Responsible-Changed-From-To: bin-bug-people->jdolecek 
Responsible-Changed-By: jdolecek 
Responsible-Changed-When: Wed Sep 13 11:46:00 PDT 2000 
Responsible-Changed-Why:  
I'll look on this. Seems like the best thing to do would be to 
implement real yacc parser. 
State-Changed-From-To: open->closed 
State-Changed-By: jdolecek 
State-Changed-When: Tue Sep 19 10:20:29 PDT 2000 
State-Changed-Why:  
Fix was implemented on -current - expr was rewritten to yacc-style 
grammar. 
Thanks for report. 
>Unformatted:

Home	PR Database Search