Subject: Re: bin/33956: -current /bin/sh possible regression
To: None <,,>
From: Greg A. Woods <>
List: netbsd-bugs
Date: 07/12/2006 16:55:03
The following reply was made to PR bin/33956; it has been noted by GNATS.

From: "Greg A. Woods" <>
To: Chapman Flack <>
Cc: NetBSD-current Users Discussion List <>,
Subject: Re: bin/33956: -current /bin/sh possible regression
Date: Wed, 12 Jul 2006 12:54:25 -0400

 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 At Tue, 11 Jul 2006 21:04:04 -0400,
 Chapman Flack wrote:
 > Rhialto wrote:
 > > In my view, the *real* problem is that the above case simply is
 > > undefined, hence any particular output is never a bug.
 > >=20
 > > Look at the manpage (from 3.0):
 > > ...
 > > This arguably only defines "$@", not if anything else is between the qu=
 > > The author of that definition simply never contemplated that case.
 > 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:
 > @   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 suspect the intent of the POSIX wording implies that the following
 should have been appended to the last sentence for clairy's sake:
 	", with the provision that the original word will still be
 	generated as one field if the $@ was embedded within a word"
 Keeping in mind that the old-fashioned way to ensure that zero
 parameters were generated when passing an ``empty'' ARGV to another
 command was to use the following simple little construct:
 thus the ``addition'' of that last rule (about generating zero fields,
 even when it is double-quoted) is relatively recent in terms of shell
 behaviour (coming in as a common requirement right about the time that
 POSIX document was first written) and so it may be the author(s)
 thinking wasn't quite so clear either.  (I suspect, though I don't
 remember for sure, that the whole "embedded within a word" behaviour was
 either documenting some common implementation or making some compromise,
 and was not the result of some really logicall thinking about the
 issue.  I suspect logically it should have embedded each parameter
 within the word, creating new fields for each parameter and produced no
 fields at all if there were no elements in ARGV.)
 Indeed, as you say, just because the _expansion_ produces zero fields
 doesn't mean the word the expansion is embedded in is not to be
 produced.  At this point that would most certainly violate the POLA no
 matter whose fence you're sitting on.  The wording is at least clear
 enough to say that the original word won't be split into two fields. :-)
 (As for NetBSD's shell(s), well any incompatability with POSIX should be
 remedied, wether it be in the documentation, behaviour, or both.)
 						Greg A. Woods
 H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <>
 Planix, Inc. <>       Secrets of the Weird <>
 Content-Type: application/pgp-signature
 Content-Transfer-Encoding: 7bit
 Version: PGPfreeware 5.0i for non-commercial use
 MessageID: vlZAboWjwJRdgqGjWltFzynUQeGrg59E