Re: Proposed new POSIX sh policy
On Sat, Nov 11, 2006, Manoj Srivastava wrote:
> 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.
You mention only one reason for switching, which is to use a faster
shell. I think there's also the fact that we want to know whether
shell scripts are POSIX shell scripts or bash scripts. If you start
sending the message that /bin/sh is bash compatible, we will lose
You may now wonder *why* we need the distinction, what the
information will be useful for. First, we might switch any such
scripts to being run by a different POSIX implementation; speed was
mentionned, but the problem might also be of running these scripts in
constrained environments, such as the initramfs. Second, not making
the distinction *gains us nothing*, quite the contrary! Anyone who
wants bash functionality can simply use bash!
Now, how to define what /bin/sh is? I would go for something
relatively minimal, such as POSIX, and add the general expectations of
script writers on top of it. For example, if test -a and test -e is
commonly supported in the shells that Debian ships, and a lot of script
writers need to use test -a and -e, then we should aim at saying
/bin/sh supports test -a and test -e, perhaps verifying that shells in
Debian support this. If most script writers expect support of "local"
in /bin/sh scripts, and shells in Debian support it, we might add such
support to the policy definition of /bin/sh capabilities.
This serves both shell scripts writers, as shell packages in Debian
which would like to be installed as a /bin/sh alternatives.
In summary, please keep the distinction between /bin/sh and /bin/bash.
I suggest defining /bin/sh starting with something like POSIX or XSG
and adding additional constraints based on common expectations on what
/bin/sh should reasonably support.
Loïc Minier <email@example.com>