From mi@misha.cisco.com Fri Jun 11 10:08:38 1999
Return-Path: <mi@misha.cisco.com>
Received: from misha.cisco.com (misha.cisco.com [171.69.206.50])
	by hub.freebsd.org (Postfix) with ESMTP id 6976C14CB5
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 11 Jun 1999 10:08:32 -0700 (PDT)
	(envelope-from mi@misha.cisco.com)
Received: (from mi@localhost)
	by misha.cisco.com (8.9.3/8.9.1) id NAA57393;
	Fri, 11 Jun 1999 13:08:31 -0400 (EDT)
	(envelope-from mi)
Message-Id: <199906111708.NAA57393@misha.cisco.com>
Date: Fri, 11 Jun 1999 13:08:31 -0400 (EDT)
From: Mikhail Teterin <mi@misha.cisco.com>
Reply-To: mi@aldan.algebra.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: something wrong with shell -- functions with arithm expressions
X-Send-Pr-Version: 3.2

>Number:         12137
>Category:       bin
>Synopsis:       something wrong with shell -- functions with arithm expressions
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    cracauer
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jun 11 10:10:01 PDT 1999
>Closed-Date:    Tue Feb 15 09:00:50 MET 2000
>Last-Modified:  Tue Feb 15 09:02:00 MET 2000
>Originator:     Mikhail Teterin
>Release:        FreeBSD 3.2-STABLE i386
>Organization:
Virtual Estates, Inc.
>Environment:

>Description:

	This strange method of figuring out  the length of a string gives
	different results for the strings of the same length depending on
	their content:

		length () {
			echo $((0 + ${#1}))
		}

		length "abc (def [xyz])"
		length "abc (def (xyz))"

	The use of ``[]'' makes the string appear one character longer. I
	made  the severity  and priority  fairly high,  because this  may
	indicate some brokenness in more important parts of sh.

	A more simple attempt to reproduce this:

		a="abc (def [xyz])"
		echo $((0+${#a}))
		b="abc (def (xyz))"
		echo $((0+${#b}))

	works as expected -- same length for both strings. So does:

		length () {
			echo ${#1}
		}

		length "abc (def [xyz])"
		length "abc (def (xyz))"

	You actually need the combination of arithmetic and function, it seems.

>How-To-Repeat:

	Just run the script above with sh. I see:
	16
	15

>Fix:

	Use bash or ksh -- they both produce 15 for both of this lines.

>Release-Note:
>Audit-Trail:

From: "Danny J. Zerkel" <dzerkel@columbus.rr.com>
To: freebsd-gnats-submit@freebsd.org, mi@aldan.algebra.com
Cc:  
Subject: Re: bin/12137: something wrong with shell -- functions with arithm 
 expressions
Date: Sun, 01 Aug 1999 13:51:38 -0400

 Mikhail,
 
 Well the addition is not required, nor does it have to be a function.
 This problem occurs when taking the length of an numbered argument value
 inside an algorithmic expression.
 
 So this displays the same error:
 
 	set -- "abc (def [xyz])"
 	echo $((${#1}))
 
 The problem appears to be that the argument variable is being parsed for
 special characters, which result in an extra character for every
 character
 in the set:
 
 	!*?[=~:/-
 
 This parsing should not occur if we are going to take the length of the
 resulting string.  Try this to see it:
 
 	set -- "!*?[=~:/-"
 	echo $((${#1}))
 
 18!
 
 This patch should fix only this problem, without any side effects:
 
 --- /usr/src/bin/sh/parser.c.orig       Sun Sep 13 15:24:57 1998
 +++ /usr/src/bin/sh/parser.c    Sun Aug  1 13:37:33 1999
 @@ -1239,7 +1239,7 @@
                 } else {
                         pungetc();
                 }
 -               if (dblquote || arinest)
 +               if (subtype != VSLENGTH && (dblquote || arinest))
                         flags |= VSQUOTE;
                 *(stackblock() + typeloc) = subtype | flags;
                 if (subtype != VSNORMAL)
 
 
 -- Danny J. Zerkel
 dzerkel@columbus.rr.com
 
Responsible-Changed-From-To: freebsd-bugs->cracauer 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Tue Jan 25 00:20:22 PST 2000 
Responsible-Changed-Why:  
Martin, Danny's patch looks good.  How about it? :-) 
State-Changed-From-To: open->closed 
State-Changed-By: cracauer 
State-Changed-When: Tue Feb 15 09:00:50 MET 2000 
State-Changed-Why:  
I committed Danny J. Zerkel's patch after reviewing it. 

Thanks for the bug report and the fix. 

It will be merged into 3.x after some testing days in 4.x 
>Unformatted:
