delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2001/03/20/15:54:42

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
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: <OF2A78BD90.820D8B96-ON88256A15.0072A954@aero.org>
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

"Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com> 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<cr>' or
'pwd<cr>' 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019