Message-Id: <200506130247.j5D2ld4f019729@delorie.com>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
To: <cygwin AT cygwin DOT com>
Subject: RE: Making /bin/sh == bash.  Has the time come?
Date: Sun, 12 Jun 2005 21:48:25 -0500
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <42ACF184.E58BC2A8@dessent.net>
X-IsSubscribed: yes

> 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()?
> 

Fork() also has to dup any and all handles/descriptors/etc, which takes all
kinds of time.

> 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()?

Something like this is on my "Master Plan Of Things I'll Probably Never Get
Around To".  I can't for the life of me figure out why anybody ever thought
that the entire fork() concept was a good idea, indeed how they ever even
thought it up ("Oh my, wouldn't it be nice if I could magically duplicate
the entire state of my app in a new process, even though there has never
been a reason to do so?"), so my life's goal is to eliminate fork() entirely
from computer science.  First step would be a shell that never forks.

-- 
Gary R. Van Sickle
 


--
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/