Subject: Re: script command
To: David Laight <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 05/01/2003 11:12:26
Thus spake David Laight ("DL> ") sometime Today...
DL> > I.e. the new feature should work like "sh -c", and thus "su -c" et al,
DL> > and that anyone wanting to use the new feature must use the new syntax.
DL> Erm sh -c doesn't (and shouldn't) work that way.
DL> sh -c -x command -y
DL> is the same as:
DL> sh -x -c command -y
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.]
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
I just R'd TFM and I note that we have added [ -c login-class ] to the
syntax. Should that have been better thought out and done as -C?
By comparison with Solaris, our sh is broken, btw: Solaris behaves
Solaris' su, as well as ours, mandates a username unless used in its bare
form. This still does not make sense to me if it is designed for
consistency, which, evidently, it appears not to have been.
...am I making any sense, here?
NetBSD: Servers' choice!