Bug 116667

Summary: line edit gets confused by non-ASCII characters in VT
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: kbdAssignee: Miloslav Trmač <mitr>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-18 15:11:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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 ***