On Tue, Nov 14, 2006 at 12:03:06PM -0600, Manoj Srivastava wrote:
> What problem exactly are you trying to solve? We have a
> working OS now, and have had one for over a decade; and we have been
> using bash all along. Reading what you say leads one to imagine all
> kinds of dire prolems that would be the case if one were to use
> bash -- but we have been using bash for all this while.
>
> So again? What is the problem you see make bash unacceptable
> here?
It's not bash that is unacceptable. It's restricting Debian to bash
_only_ that is unacceptable.
You mentioned different shells shadowing different utilities. But thanks
to the "enable" command, that's true for two bash scripts as well -
looking at an "if test ... then ..." construct in a #!/bin/bash script
you never know whether that "test" command will invoke the bash builtin
or the external /bin/test utility without deeper analysis of the script.
On the other hand, for a #!/bin/sh script you know that you only have to
check the /bin/sh symlink to decide what "test" means.
Right now configure scripts can be speeded up by making /bin/sh point to
something other than bash. If you mandate /bin/sh to always be bash,
then it suddenly becomes a valid optimization to turn cat, sed, rm, grep
etc. into bash builtins thus cutting down the number of fork()/execve()
calls by about 60-70% (for just this 4 commands alone) - you just need a
patched autoconf that inserts the appropriate "enable" commands at the
beginning of the configure script. But that means command shadowing
becomes worse and harder to diagnose than enabling different shells as
/bin/sh.
There are probably a lot of other areas where such tricks could be used.
Thanks to the "enable" command, you can even turn bash into a (much more
bloated) busybox.
I say that restricting /bin/sh to just one possible value does not solve
the complexities of having different shells as /bin/sh. You just trade a
well-known (and already handled) complexity for a much-less-known
complexity.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
