[ Argh!  Forgot to Cc to the list, again! ]

In article <20030501194449.M26297@snowdrop.l8s.co.uk> you write:
>> A bit far afield but since the common direction seems to be touting
>> POS-ix, one would think that sh knew how to parse options in a similar
>> manner to, or in fact use, getopt(3), and abide by its constructs; i.e.
>> 
>> sh -c -x command -y would (try to) execute "-x", while
>> sh -x -c command -y would (try to) execute "command".

That's incorrect.  POSIX specifies that <command_string> ("command" above)
is an operand, not an option-argument, that -c doesn't take an
option-argument, and that "sh" conforms with the Utility Syntax Guidelines
(with an irrelevant exception).  Thus, the two commands above are
equivalent.

>> [note that quotes are needed around "command args..." in order to get
>> it to work properly.]

Indeed.  Your examples above set $0 to "-y" for the duration of "command",
which might not be what was intended.

>sh -c "command args" will look for a file command\ args, not execute
>command with args.

That's incorrect.  POSIX specifies that <command_string> "shall be
interpreted ... as if the string were the argument to the system()
function".  Thus, it's a little shell script in its own right.

>su is funny in posix - because 'su -' is required to behave in its
>tradional manner - which doesn't have any arguments except the'-'.

su is explicitly not specified by POSIX.

>> By comparison with Solaris, our sh is broken, btw:  Solaris behaves
>> as expected.

Be very careful using Solaris /bin/sh as an example of anything.  It's
strongly non-POSIX-compliant.  Their POSIX shell is /usr/xpg4/bin/sh.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>