--pgp-sign-Multipart_Wed_Jul_12_12:54:21_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Tue, 11 Jul 2006 21:04:04 -0400,
Chapman Flack wrote:
>=20
> 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=
otes.
> > The author of that definition simply never contemplated that case.
>=20
> 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:
>=20
> @   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.
>=20
> 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:

	${1+"$@"}

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.)

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Wed_Jul_12_12:54:21_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: vlZAboWjwJRdgqGjWltFzynUQeGrg59E

iQA/AwUBRLUpP2J7XxTCWceFEQLwIwCgg/KJjNdxdExSj+sSGtVq6nlx86gAoOUi
CfRuVph71s9J6YoxXeLPPN0E
=f04i
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Wed_Jul_12_12:54:21_2006-1--