Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <38EA2AFA.45837D0D@veritas.com>
Date: Tue, 04 Apr 2000 10:48:42 -0700
From: Bob McGowan <rmcgowan AT veritas DOT com>
Organization: VERITAS Software
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: stefan <stefan AT lkcc DOT org>
CC: Cygwin Mailing List <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: bash: bug or feature
References: <Pine DOT LNX DOT 4 DOT 10 DOT 10004041722520 DOT 1445-100000 AT bono DOT reversers DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

stefan wrote:
> 
> hello cygwin'ners:
> 
> we are using the cygwin environment for software development purposes.
> unfortunately the bash implementation of the standard package b20.1 is
> sooo slow.
> when you are keep keys down (arrows) to go through command lines it even
> produces invalid characters. why is this ? and how could we work around it
> ? did ever anyone thought of a gui frontend for the bash to speed it up ?
> 
> thanks in advance...

Stefan,

The Cygwin environment tries to emulate the UNIX way of doing things
(and does a very good job, too).  One of the features of UNIX tty's (the
"standard" way of getting input into the system) is that it deals with a
'character set', not scan codes (as produced by the keyboard.  Think
"terminal" serial line here.).  So every key pressed must have an
associated character or series of characters.  Every ASCII character is
represented by a specific key (generally, though sometimes a character
may be missing and control characters are a special case of a single
character generated by a two key input), but there are no ASCII
definitions for "Up Arrow" or "Home" keys, etc.  So, the system
generates a short series of characters for these keys, beginning with
the ESC character followed by 2 or 3 additional characters which define
the key's function.

I believe the problem your seeing is timing related, having to do with
things like speed of input versus speed of program operation and maybe
input buffer size.  The arrow key character sequence, for example, would
not be recognized if a character were dropped, and so would cause output
of invalid characters.  Also, UNIX applications that allow use of
special keys often use internal timing mechanisms to try and separate a
plain ESC key from an "escape sequence".  The UNIX editor vi is
notorious for this, since you use the ESC key (alone) to signal end of
text input.  So it times the lapse between an ESC and the next character
on the input.  If it falls below a certain level, vi assumes it is an
"escape sequence", otherwise it assumes the single character.  I don't
know bash code, but perhaps it is using a similar technique?  And if the
time is too long, the "escape sequence" becomes a simple character
sequence, resulting in "invalid" characters.

I would also note that I am not seeing any of the slowness you mention,
nor do I get the invalid character problem from bash, even when I scroll
the history list as fast as the keyboard auto repeat lets me.  I am
using the Cygwin CD version 1.0 on a 500 MHz system with 128 MB RAM. 
This may also be a factor, if you are running on a very slow machine or
have little memory.

And I really don't see how putting a GUI front end on bash would speed
anything up.  I'd think it would actually slow it down.

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan AT veritas DOT com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com