Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-Id: <4.3.2.7.0.20001013182952.00c42390@pop.bresnanlink.net> X-Sender: cabbey AT pop DOT bresnanlink DOT net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Oct 2000 18:36:14 -0500 To: cygwin AT sourceware DOT cygnus DOT com From: Chris Abbey Subject: RE: WinNT Lockup In-Reply-To: <4.3.1.2.20001013151952.02305280@pop.ma.ultranet.com> References: <555095BDC488D21192E600104B66477302D43E48 AT smtp DOT ally DOT 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 AT sourceware DOT cygnus DOT com