Subject: bin/4547: buggy parameter expansion in /bin/sh
To: None <gnats-bugs@gnats.netbsd.org>
From: Developer Account <devel@beleriand.joern.loc>
List: netbsd-bugs
Date: 11/20/1997 20:05:42
>Number: 4547
>Category: bin
>Synopsis: buggy parameter expansion in /bin/sh
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: bin-bug-people (Utility Bug People)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Nov 20 11:20:03 1997
>Last-Modified:
>Originator: Joern Clausen
>Organization:
Faculty of Technology, University of Bielefeld, Germany
>Release: 1.2
>Environment:
System: NetBSD beleriand 1.2 NetBSD 1.2 (BELERIAND) #9: Wed Oct 1 00:21:47 MET DST 1997 nbsd@beleriand:/usr/src/sys/arch/amiga/compile/BELERIAND amiga
>Description:
The parameter expansion of /bin/sh w.r.t ${foo:=bar} is buggy. Neither
does it conform to the described behaviour in the man-page, nor does it
behave similar to most other shells or POSIX.
>How-To-Repeat:
The problem occured first to me with a script from teTeX, where this
sequence of commands appeared:
fullname=`kpsewhich "$NAME.tfm" 2>/dev/null`
: ${fullname:=`kpsewhich "$NAME.mf" 2>/dev/null`}
The second line caused the program "kpsewhich" to be called over and
over again.
Trying to figure out what *exactly* happens, I came up with these
scripts, to help me see the flow of control and arguments. Alas,
I'm now more confused than before:
The script "showargs" simply repeats its arguments:
#!/bin/sh
echo my arguments are[$$]: $*
This script then triggers the bug:
#!/bin/sh
echo ${foo:=`showargs ABC DEF`}
echo $foo
On Solaris 2.4, this gives the expected result:
my arguments are[10942]: ABC DEF
my arguments are[10942]: ABC DEF
But on NetBSD, the result is
my arguments are[1865]: ABC arguments are[1865]: ABC DEF
my arguments are[1865]: ABC DEF
I have included the pid, as I thought, two backtick evaluations
occur (something like this *seems* to happen, otherwise I can't
explain the loop of the teTeX script above), but in this case,
the result string seems to be concatenated twice, with the last
argument of the first part replaced with the "cdr" (to say it in
LISP) of itself.
I'm not sure if this observation is correct, I'm not even sure
if I made myself clear what happens, I just know *something* is
wrong here.
>Fix:
Sorry, no.
>Audit-Trail:
>Unformatted: