Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-Id: <4.3.2.7.0.20001013182952.00c42390@pop.bresnanlink.net>
Date: Fri, 13 Oct 2000 18:36:14 -0500
To: cygwin@sourceware.cygnus.com
From: Chris Abbey <cabbey@chartermi.net>
Subject: RE: WinNT Lockup
In-Reply-To: <4.3.1.2.20001013151952.02305280@pop.ma.ultranet.com>
References: <555095BDC488D21192E600104B66477302D43E48@smtp.ally.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

You can recreate this under cmd if you dynamically adjust your path; they seem
to do some caching someplace... cause the first few commands that have to go
to the end of the path take forever right after you make an update to the path.

There's also a difference that bash looks at things like file mode for an
x bit, whereas cmd just looks for a filename (dir then stat, vs dir) but
if the code is ordered right, the stat is only after a matching filename. ;)

At 15:24 10/13/00 -0400, Larry Hall (RFK Partners, Inc) wrote:
>Bash would eventually have something similar to say.  Once all the
>directories listed in PATH are checked or time out, bash will give something
>like "file not found".  Assuming the PATH variable for bash is the same as
>in CMD (which it doesn't have to be and is not by default, if I remember
>correctly), bash will still be a bit slower than CMD searching for the same
>command since it has to go through emulation code in Cygwin.  Some of the
>path handling code is not optimal either.
>
>Larry


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com