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

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
 valuable information.
   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 <lool@dooz.org>

Reply to: