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 <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
