> 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".
> 
> [note that quotes are needed around "command args..." in order to get
> it to work properly.]

Indeed our shell does obey posix (since I fixed it a few months ago).
The synopsis has:

     sh -c [-aCefnuvxIimqVEb] [+aCefnuvxIimqVEb] [-o option_name]
	[+o option_name] command_string [command_name [argument ...]]

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

> Regarding su:  Since 'su' with no args denotes 'su root', should not
> "su -c 'command args...'" execute "command args"?  Perhaps that's
> not the way it's ever worked, but it would seem to make the most sense.
> Otherwise we should *gag choke* _require_ a username and not assume
> a default -- or does that break other things (like user habits and
> POS-ix compliance)?

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

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

in what way do you mean 'expected' ?

	David

-- 
David Laight: david@l8s.co.uk