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

Re: Proposed new POSIX sh policy

On Sun, 05 Nov 2006 19:41:40 -0800, Russ Allbery <rra@debian.org> said: 

> Russ Allbery <rra@debian.org> writes:
>> Manoj Srivastava <srivasta@debian.org> writes:

>>> This flows from the Release policy. Not specifying /bin/bash in
>>> scripts is not considered a RC bug.

>> I can try to propose better language for this.  I think that using
>> pure bash-specific constructs not found in dash in /bin/sh scripts
>> should actually be an RC bug, but using test -a or test -o should
>> not.  I think we need to say that /bin/sh scripts are permitted to
>> use POSIX shell capabilities plus a short list of additional
>> capabilities that everything other than posh also implement.

> Here's a proposed patch.  What do people think about this approach?
> I know there was an inconclusive Policy discussion a while back
> about how best to deal with this issue.  As you can tell from this
> patch, I favor the approach of documenting the specific features
> that we require and assuming that their semantics are sufficiently
> clear in practice.

        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? We can't, in all honesty, say that any disk
 space is conserved, since bash is essential, it is too deeply rooted
 in all places in our system to be casually ripped out.

        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.

        So why not just specify all maintainer scripts just use
 /bin/bash? I am not sure. Perhaps because allowing scripts to specify
 /bin/sh would allow then to be sped up a trifle when /bin/sh is a
 nimbler shell? Is this worth the complexity? we speed up  install
 times of packages a wee bit at the expense of a much more complicated
 policy document? (I know some people think we can move bash out of
 Essential one of these days, and well, I think that is mere wishful
 thinking and a pipe dream).

        I personally don't think so.

        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.

        It would, at one fell swoop, solve the problem Thomas hinted
 at before, about our specification allowing shell to randomly shadow
 other commands on the system.

        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).

apostrophy: when your apostrophe atrophies. David Bedno
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: