Subject: Re: bin/33956: -current /bin/sh possible regression
To: None <,,>
From: Rhialto <>
List: netbsd-bugs
Date: 07/12/2006 01:25:02
The following reply was made to PR bin/33956; it has been noted by GNATS.

From: Rhialto <>
To: Chapman Flack <>
Cc: Rhialto <>,
	David Holland <>,,,
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Wed, 12 Jul 2006 03:20:59 +0200

 On Tue 11 Jul 2006 at 21:04:04 -0400, Chapman Flack wrote:
 > Reasoning from the weaknesses of our own man page isn't dispositive,
 > though, because even our man page says that [a]sh is intended to
 > implement the POSIX semantics, which are defined:
 Well, ok, I was wondering what POSIX would say. But I think I have a
 fair point that I can only judge NetBSD behaviour by actually included
 NetBSD documentation, which according to my recollection follows
 historical documentation pretty closely in this case (looking at the
 sh(1) of my ULTRIX 4.0 grey wall, I even see that it writes no more than
     "$*" is equivalent to "$1 $2 ..." whereas
     "$@" is equivalent to "$1" "$2" ... .
 which strengthens my idea that originally this case was not
 > @   Expands to the positional parameters, starting from one. When the
 >    expansion occurs within double-quotes, and where field splitting
 >    (see Field Splitting) is performed, each positional parameter shall
 >    expand as a separate field, with the provision that the expansion of
 >    the first parameter shall still be joined with the beginning part of
 >    the original word (assuming that the expanded parameter was embedded
 >    within a word), and the expansion of the last parameter shall still
 >    be joined with the last part of the original word. If there are no
 >    positional parameters, the expansion of '@' shall generate zero
 >    fields, even when '@' is double-quoted.
 > Granted, even that wording would win no contests for precision, but it
 > does cover the case almost completely. In the particular case of NO
 > positional parameters, it could technically be read to allow either
 > "foo  bar" or nothing at all as the expansion of "foo $@ bar", but that
 > seems more an artifact of the writing than an intent of the spec; both
 > existing practice and POLA would tend to rule out the 'nothing at all'
 > interpretation.
 I think someone noticed that people were using $@ in a way that was not
 intended, and wrote up a sort-of sensible definiton for it after the
 fact. Personally I would not cry if all configure scripts with "Checking
 $@ ..." would cause d(a)emons to fly out of the author's nose. They
 could equally well write $* instead (and I might even refrain from
 arguing that it would be undefined too ;-)
 > -Chap
 ___ Olaf 'Rhialto' Seibert      -- You author it, and I'll reader it.
 \X/ rhialto/at/        -- Cetero censeo "authored" delendum esse.