Re: Proposed new POSIX sh policy
On Sat, 11 Nov 2006 23:10:52 -0600, Manoj Srivastava
<srivasta@debian.org> said:
> OK. How about we again step back, and examine the rationale
> behind this, and the use cases that we intended to support? Look,
> bash is essential, and ships as /bin/sh; nothing is required as far
> as systems integration requires in order to specify anything in
> policy, really -- policy could just take the approach /bin/sh ==
> bash, and stop worrying about bashisms or any standards compliance
> beyond what bash already supports.
> Why don't we do that? Because people wanted to have a
> different shell that can serve as /bin/sh. What purpose does it
> serve to allow that?
> One thing I see happening is that replacing bash as /bin/sh
> might make script startup ties a bit faster, at the expense of soe
> of the built in facilities and extensions present in bash.
> So, the goal seems clear: to specify enough in policy so
> that at least maintainer scripts do not break if /bin/sh is not
> bash -- or that they use /bin/bash as the interpreter.
> It is my opinion that we would be better off dumping this
> whole shell specification thing in policy, standardizing on bash,
> and let it go.
> If people really think we need to keep this problematic part
> in policy, please put forth you rationale, and the use case you
> think you want supported, and why it needs to be policy at all (as
> opposed to a developers reference good practice thing).
Let me see if I can summarize the rest of the discussion.
a) Freedom of choice: it should be possible forusers to us a non-bash
shell as /bin/sh, and we should not put needless obstcles in their
path.
b) Speed. Faster boot times, faster script execution. This seems to be
important for some people. Older hardware is a use case.
c) memory footprint -useful for older or embdded hardware. Having
scripts tun also with busybox would help embedded folks a lot
d) storage footprint -- this is stil useful for embdded systems, where
bash, despite being essential, can still be dumped, since the
package selection can be very restricted and non standard.
e) bash dependencies on libnss-* libs that live in /usr prevent /usr
from being umounted cleanly.
Jari Aalto -- a, b, c
David Weinehall -- b, c, d
Mark Brown -- b
Bruce Sass -- b
Mike Hommey -- b
Gabor Gombas -- e
Marco d'Itri -- b
So, there seem to be a strong sentiment that we should not
standardize on bash :) I suggest we not standardize what /bin/sh is
at all, instead we concentrate on just the maintainer scripts.
So, rather than specifying what /bin/sh is supposed to be,
with all the issues about shadowing binaries etc, we start with
specifying what the maintainer scripts must comply with.
So first, maintainer scripts may continue to use essential
package4s on the system, namely bash, but we add in a note that one
should not sue use bash specific things, but instead it is preferred
that maintainer scripts comply with a minimal set of features, as far
as possible. Too many RC bugs if we try and disallow bash in
maintainer scripts even with a proper magic #! line.
So, what features do we settle on? we can either standardize
on, well, a standard: POSIX/SUSv3, -- but there are things we use
that come from XSI. I guess we could standardize on SUSv3 +XSI
shells. Would still make local illegal:). The issue here sems to be
that we are beginning to see people want to add in various and sundry
features which are not pure POSIX just because people have been using
it in their scripts.
The other way would be to select a bunch of shells that
scripts must run with. This means we move away from depending on
standards, and move to depending on implementations, warts and all.
Suggestions have been to use dash or busybox; which would serve as
the lowest common denominator. The lowest denominator must not be
too different from what people are used to, or else they would just
switch to using bash, which would defeat the purpose.
is there a way to test if a script has errors, a la bash -n
using busybox?
manoj
--
"Take off your engineering hat and put on your management hat."
Thiokol management, 1/27/86
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: