This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Keypress anomaly: maybe locality specific


On Mon, Jan 26, 2004 at 01:14:07PM -0000, fergus@bonhard.uklinux.net wrote:
> Windows XP. The anomaly happens in Cygwin 1.5.6 and 1.5.5 and maybe earlier
> still, but I have no way of confirming this ... it's a bit parochial (may be
> UK specific, I think) but I'd like to describe it here as, I hope, an easily
> identifiable and curable anomaly.
> 
> This comes to you from the UK. If I set keyboard= language= everything else=
> US within Windows, and operate from the sparsest possible bash console
> within Cygwin, everything works fine. The symbols I get on screen don't
> quite match what is painted on the keys I pressed, but that's as expected,
> because my keyboard is a UK one. Usually it's one-one. In a small number of
> cases one ends up playing a kind of connected game of chase, running through
> @ and " and also \ and | and ~ before learning what gives what. In
> particular <Shift-3> gives the hash symbol #, even though what's painted on
> the key is a £ sign (UK pound). I have found no way of actually getting a £
> sign, but nor can I get a whole load of other symbols, currency and all
> sorts, so this is no surprise.
> 
> Now use the Control Panel to change at the Windows level to keyboard=
> language= everything else= UK (my standard settings, in fact). Now there's
> an exact match between what's painted on the keys and what appears on screen
> for all of " and @ and ... and now <Shift-3> gives £, as painted on the key.
> 
> It is what I get in Word, at the XP Command Prompt, in Notepad and all the
> rest.
> 
> I even get it in nano-within-Cygwin and vim-within-Cygwin.
> 
> But, oddly, at the bash command line in Cygwin I get not a GB pound sign £;
> and not even the hash sign #; but actually a two key combination # + Enter,
> so that one gets taken to a new, empty, command line. The hash sign alone is
> printed. If I type
> 
>     $   789<Shift-3> (don't press Enter)
> 
> what I get on screen is
> 
>     $   #789
>     $
> 
> so the hash is printed at the start of the line AND an <Enter> is assumed.
> 
> There is probably a level (e.g. "printers") at which an emailed query about
> weird behaviour would quite rightly get the response "It's your printer,
> you're on your own". I appreciate the somewhat locality-specific nature of
> this query, but have I explained it sufficiently to suggest that it
> shouldn't be happening, even in a minority situation, and maybe for cause
> and cure to be evident to somebody who can implement that cure?
Hmm.. another case of weirdness staring me in the face..
Off the top of my hat (WAG-style) I'd say this looks like a readline problem..

If you're willing to bare with me on some now-try-this debugging, I might be
able to help you out.. Unfortunately, I do not have a UK keyboard :(

In any case, the first thing needed would be a cygcheck output (attached) as
described in http://cygwin.com/problems.html. After that, I can either provide
you with some "now try this" instructions (involving compiling Bash) or provide
you with some specially-compiler Bash versions to see whether they behave 
correctly.

First, though, the cygcheck output would be nice, and it would be nice to know
if there are any other programs than Bash that have this problem..?

rlc

-- 
Just remember, wherever you go, there you are.
		-- Buckaroo Bonzai

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]