[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
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?

"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: