Re: Making /bin/sh == bash. Has the time come?

[Brian Dessent <brian at dessent dot net>]

Christopher Faylor wrote:

> Recently, after too many hours hacking at vfork corner cases, I came to
> the conclusion that getting vfork working correctly was too difficult
> so, I turned off vfork in cygwin and asked Corinna to modify ash to use
> /bin/sh again.

I assume that should read "modify ash to use fork() again."

Can I just ask a basic question here?  So if both ash and bash are using
the same method of execution (fork), is the reason for bash's slowness
due to it just being a larger program with more pages to copy during a
fork()?

And a related question: Would it make more sense to compile ash with all
its builtins enabled, rather than switching to bash?  It seems from the
benchmarks that bash loses in speed due to its large size, but wins a
lot back by having builtins that it can use for many features.  If
ash+builtins is still smaller than bash, wouldn't it solve both
problems?  (Of course if configure scripts choose bash automatically if
present, then that sort of throws a wrench in that logic.)

Final question: It seems to me that most of what a shell does for most
common things is essentially "fork(); ... exec(); ... wait();".  I'm
sure there's an obvious reason why the following is not feasible, but
would it be possible to special case this in the shell to use something
that maps closer to the win32 api like spawn() so as to avoid having to
fork()?

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/