Bug 116667 - line edit gets confused by non-ASCII characters in VT
Summary: line edit gets confused by non-ASCII characters in VT
Keywords:
Status: CLOSED DUPLICATE of bug 143014
Alias: None
Product: Fedora
Classification: Fedora
Component: kbd
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Miloslav Trmač
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-02-24 09:47 UTC by Alexandre Oliva
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-02-18 15:11:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2004-02-24 09:47:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040217

Description of problem:
If you enter non-ASCII characters in a VT bash session, line editing
gets very confused.  For example, if you enter � (it won't be
displayed; it's easy to enter it if you configure the keyboard as US
International), then a blank, then backspace twice, you'll get back
one more space than you moved forward.  Do it several times, and
things quickly get very confusing.  If you have such `hidden'
characters and you type until you reach the end of the line, bash will
issue carriage returns without line breaks, so you'll end up
overwriting the first line instead of continuing a long line in the
next line.

Version-Release number of selected component (if applicable):
bash-2.05b-37

How reproducible:
Always

Steps to Reproduce:
1.Enter a few `�' characters, then a blank, then backspaces.
2.Enter a few `�' characters, then a long command line that doesn't
fit in a single line on the screen

Actual Results:  1. gets you back into the prompt
2. line-wraps onto the same line

Expected Results:  Ideally, � should be displayed, if not as itself,
as a blank or some other ASCII character to represent it, and then
everything would probably work.

Additional info:

Comment 1 Tim Waugh 2004-02-24 09:52:07 UTC
Changing component (bash has its own readline).

Comment 2 Tim Waugh 2004-02-24 09:54:17 UTC
Need to know what locale you are using.  Can you confirm that the
character you are typing is a question mark (query) inside a circle?

Comment 3 Alexandre Oliva 2004-02-24 13:11:29 UTC
Ugh.  The character is an a with an acute accent: á.  Dunno why it
didn't make it properly.

locale is en_US.UTF-8.

Comment 4 Tim Waugh 2004-02-24 13:17:25 UTC
Can't reproduce this.  Which terminal are you using?

Comment 5 Alexandre Oliva 2004-02-24 13:30:14 UTC
VT1 (text console).  Whatever terminal emulation that implies.

Comment 6 Tim Waugh 2004-07-28 08:30:23 UTC
Can you still reproduce this?

Comment 7 Alexandre Oliva 2004-07-29 04:23:58 UTC
'fraid so, with yesterday's rawhide.

Comment 8 Tim Waugh 2004-07-29 09:01:43 UTC
Can you try bash-3.0-1 please?

Comment 9 Alexandre Oliva 2004-07-30 07:02:37 UTC
No change :-(

Comment 10 Tim Waugh 2004-07-30 08:09:59 UTC
I'm afraid I haven't been able to reproduce this here.

Comment 11 Alexandre Oliva 2004-07-30 10:11:04 UTC
Mind telling me what you tried?  I can readily duplicate it on FC2 and
FC3test1, on a UTF8 locale and with the us-acentos keyboard
configuration on a text console.  Note I'm not talking about random
terminal emulators, I'm talking about the terminal you get after
switching to VT1 with Ctrl-Alt-F1.

Comment 12 Tim Waugh 2004-08-03 14:44:26 UTC
I switched to VT1 and followed your "steps to reproduce" in the
original report.

If you can repeat this 100% please try rephrasing how to get this to
happen, telling me which keys to press and in which order -- I wasn't
sure if I needed to press return or anything (I didn't).

I have a US keyboard here: all of the test machines I have access to
do. :-(  I had to put an a-acute in .bash_history and use C-k/C-y. 
Tell me a better way to do this.


Comment 13 Alexandre Oliva 2004-08-09 04:44:41 UTC
Aha!  So you didn't configure the keyboard as US-International
(us-acentos in /etc/sysconfig/keyboard)?  I suspect that's a key step
to duplicate the problem, because us-acentos generates iso-8859-1 even
if the default locale is UTF-8.  It appears that this is what bash
doesn't like: incomplete multi-byte sequences.

Comment 14 Tim Waugh 2004-08-09 10:55:11 UTC
Sounds like us-acentos needs to be fixed.  All bets are off if there
are incomplete multi-byte sequences -- there isn't any good behaviour
in that case.

Comment 15 Eido Inoue 2004-08-10 22:13:39 UTC
has multibyte compose sequences been fixed in the kernel yet? if not,
this bug is blocked

Comment 16 Miloslav Trmač 2005-02-18 15:11:10 UTC
As a work-around, you could choose a keymap that doesn't need dead keys
or compose to produce the characters you need, and load it using
loadkeys -u.


*** This bug has been marked as a duplicate of 143014 ***


Note You need to log in before you can comment on or make changes to this bug.