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 Subject: Re: Possible globbing error in bash 2.04.7(2)? To: cygwin AT sources DOT redhat DOT com From: Brian DOT P DOT Kasper AT aero DOT org Date: Tue, 20 Mar 2001 12:53:23 -0800 Message-Id: X-MIMETrack: Serialize by Router on ladir01/AeroNet/Aerospace/US(Release 5.0.5 |September 22, 2000) at 03/20/2001 12:53:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii "Larry Hall (RFK Partners, Inc)" wrote: >You forgot to add "mkdir tt"!:-) Doh! That's because I made it outside the script. Mea culpa. Here's a diff to patch the script: 4a5,6 > mkdir tt > >Hm, this works for me using: > >GNU bash, version 2.04.7(2)-release (i686-pc-cygwin) >and >1.1.8(0.34/3/2) 2001-01-31 10:08 i686 unknown > >I ran it until i = 836 like you did without a problem. It did slow down >significantly though (observed guess of a factor of 2). Maybe the issue >you're noticing is actually a Cygwin problem. That's possible; I've been seeing the problem for a long time, certainly with the 1.1.6-1.1.8 dlls. FWIW, I noticed the same slowdown you did (this is why I aborted at i = 836; I didn't want to wait!). Some new information: when I execute 'ls *' from a WinNT command prompt, the error doesn't occur. This leads me to think that the problem may lie with bash, but it certainly could be cygwin. I still haven't been able to reproduce the first problem I described, in which bash blocks after a command is entered until ^C is hit (apparently, I've tripped the bug's "attempt to demonstrate" sensor), but I realized I forgot to include one bit of context which might be helpful. The first bug I listed in my original post was >1) After a command is entered, bash will block until ^C is pressed, > at which point a Windows error dialog will pop up (I can't get the > error to occur right now, dammit, or I'd include more details) I originally had my CYGWIN var set to "binmode ntsec". In that case, bash was basically unuseable. I backed off to "binmode ntea", and the problem became less common. When I finally changed to "binmode" only, the problem became *really* infrequent (but it still occurs). Also, it seemed like using a builtin would sometimes reset something so that non-builtin commands could succeed. For example, typing 'cd' or 'pwd' would occasionally result in subsequent non-builtin commands succeeding. -Brian kasper AT aero DOT org -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple