Subject: Re: script command
To: None <firstname.lastname@example.org>
From: Ben Harris <email@example.com>
Date: 05/01/2003 20:48:31
[ 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
>> [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 <firstname.lastname@example.org>
Portmaster, NetBSD/acorn26 <URL:http://www.netbsd.org/Ports/acorn26/>