Subject: bin/4547: buggy parameter expansion in /bin/sh
To: None <>
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
>Originator:     Joern Clausen
Faculty of Technology, University of Bielefeld, Germany
>Release:        1.2
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
   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.
   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 "$" 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:

     echo my arguments are[$$]: $*

   This script then triggers the bug:

     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.
   Sorry, no.