Bug 74925 - Backspace deletes prompt after entering non-ASCII characters
Summary: Backspace deletes prompt after entering non-ASCII characters
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bash
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
: 71684 81553 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-02 20:29 UTC by Milan Kerslager
Modified: 2007-04-18 16:47 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-10-18 10:17:43 UTC

Attachments (Terms of Use)
Patch to make readline init from bash variables instead of original environment (663 bytes, patch)
2002-10-10 03:01 UTC, Miloslav Trmac
no flags Details | Diff
The patch make readline init from bash to use environment variables (e.g. LC_CTYPE) from file /etc/sysconfig/i18n if locale is not determined (setlocale return "C" or "POSIX") (1.01 KB, patch)
2002-10-16 16:16 UTC, Need Real Name
no flags Details | Diff
Similar bash-2.05b-LC_CTYPE.patch only for readline-4.3-3 package (989 bytes, patch)
2002-10-16 17:06 UTC, Need Real Name
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2003:140 normal SHIPPED_LIVE Updated bash packages fix several bugs 2003-06-23 04:00:00 UTC

Description Milan Kerslager 2002-10-02 20:29:01 UTC
If I enter a non-ASCII character on the command line and after that press
backspace, two characters to the left will be deleted instead of just the one I
entered, erasing part of the shell prompt.

Seems like readline bug a saw here before. UTF-8 multibyte characters are
treated as more chars and not as one.

I tryed to use de-latin1 keymap. But my native language is Czech so I need to use:

loadkeys -u cz

because we have keyboard maps in ISO-8859-2. Same problem (try to press number 2
on alphabetic keypad, then try to delete them by pressing backspace) az with DE

Comment 1 Tim Waugh 2002-10-07 14:21:50 UTC
Is this over an ssh connection, or on the local machine?  If the local 
machine, is it inside a graphical terminal or on a text-mode console?

Comment 2 maxa 2002-10-07 17:00:28 UTC
I have the same problem although I use fi-latin1 keyboard layout. The problem
occurs on text-mode console (tty). The command line behaves well as long as
there's no special character as 'v','d','=',''','#' or '5'. 

How to reproduce:
1. Enter about 30 '='-chars (1/2, half-sign) and the cursor will jump to the
beginning of the line and start to overwrite the prompt.
2. Enter a long line with typical a-z chars. Add one '='-char and next time when
there should be a new line the cursor will jump to the beginning of the line.
3. If you use backspace with long lines that contain '=' the whole command line
becomes messed.

Comment 3 maxa 2002-10-07 17:08:21 UTC
As we can see bugzilla can't handle any non US-ASCII chars....
Here are some of the chars that can be used when reproducing the problem.

small a, dieresis = ä = ä
small o, dieresis = ö = ö
sestion sign = § = §
pound sterling = £ = £

Comment 4 Milan Kerslager 2002-10-08 12:12:13 UTC
The problem is on text console (tty).

Comment 5 Pekka Savola 2002-10-09 12:19:54 UTC
Happens with us too, fi-latin1.

Comment 6 Tim Waugh 2002-10-09 12:29:42 UTC
Probably a duplicate (side-effect) of bug #74701.

Comment 7 Christian Rose 2002-10-09 17:27:18 UTC
Isn't this a duplicate of bug 68313? Seems like that one never was properly fixed.

Comment 8 Tim Waugh 2002-10-09 17:32:01 UTC
It might be.  But although it has the same symptom, it may well be a different 
It's odd though that executing 'bash' (i.e. a subshell) makes the problem go 
away.  It does for me at least.

Comment 9 Milan Kerslager 2002-10-09 18:29:48 UTC
#68313 is not a public bugreport and has been already closed. So I decided not
to reopen it.

Comment 10 Miloslav Trmac 2002-10-10 02:59:58 UTC
This has the same basic cause as bug 74701 (bash uses environment at the time of
its startup, not current values seen on its command line). Attached patch fixes
it for me. It depends on the patch attached to bug 74701, which makes bash
apply variables set in /etc/profile.d/lang.sh.

#include <rant/about/non-public/bugreports.h>

Comment 11 Miloslav Trmac 2002-10-10 03:01:59 UTC
Created attachment 79725 [details]
Patch to make readline init from bash variables instead of original environment

Comment 12 Lee Wilson 2002-10-10 22:38:53 UTC
Happens to me as well, although only when pressing the # (GB Pound)symbol when 
using text console. UK keyboard (I think the keymap is en_GB.UTF-8, taken 
from /etc/sysconfig/i18n).

Keyboard works find inside X and as previously said when starting up a sub-
shell it works fine as well.

Just performed further tests only happens when using bash as the shell.  When 
using csh the problem is not there.  

Sorry if I am stating the obvious but does look like a bash problem rather than 
any settings.

Comment 13 Tim Waugh 2002-10-11 11:15:19 UTC
*** Bug 71684 has been marked as a duplicate of this bug. ***

Comment 14 Need Real Name 2002-10-16 16:16:15 UTC
Created attachment 80669 [details]
The patch make readline init from bash to use environment variables (e.g. LC_CTYPE) from file /etc/sysconfig/i18n if locale is not determined (setlocale return "C" or "POSIX")

Comment 15 Tim Waugh 2002-10-16 16:33:12 UTC
corwin@micom.net.ru: Did you see the patch already attach to bug #74701?

Comment 16 Need Real Name 2002-10-16 16:58:48 UTC
This problem arises for the following reason:
After execution of login program the first cinstance bash (as login shell) is
started. In this
moment environment variables LC_* are not defined yet (for this instance of
bash). After call
setlocale(), bash executes own init scripts (e.g./etc/bashrc
and/etc/profile.d/*.sh). In the
script /etc/init.d/lang.sh (by /etc/sysconfig/i18n or ~/.i18n) variables LC_*
and/or LANG are
defined. Therefore in the first instance of bash locale is set as "POSIX" (or
"C"). In other
instances (where SH_LVL >= 2) locale is set as variables LC_*. For this reason
the following
functions incorrectly work: mbrlen(), mbrtowc() and etc. (incorrectly determined
length of
the single Non-ASCII character).

In a patch bash-2.05b-LC_CTYPE.patch I have changed initialization readline as
First we set LC_CTYPE category in value defined by environment variables (call
If LC_CTYPE is equal "C" or "POSIX" (may be locale is not set?) we look
variables defined in
/etc/sysconfig/i18n file in following order LC_ALL, LC_CTYPE, LANG. If one of
these variables
is defined, then set LC_CTYPE category.

In this case the first instance of bash also uses LC_CTYPE category defined by
/etc/sysconfig/i18n file
(or ~/.i18n )and works fine with UTF-8 codings

Comment 17 Need Real Name 2002-10-16 17:04:35 UTC
The similar patch needs to be applied and to readline-4.3-3 package

Comment 18 Need Real Name 2002-10-16 17:06:15 UTC
Created attachment 80684 [details]
Similar bash-2.05b-LC_CTYPE.patch only for readline-4.3-3 package

Comment 19 Tim Waugh 2002-10-16 17:09:09 UTC
corwin@micom.net.ru: mitr@volny.cz has already submitted a patch for this bug
(bash-2.05b-readline-init.patch, which follows on from the patch attached to bug
#74701)---is there some reason that your patch is better?

Comment 20 Miloslav Trmac 2002-10-17 07:33:44 UTC
I believe the patches from corwin@minicom.net.ru are wrong, though
I may be of course mistaken.
bash-2.05b-LC_CTYPE.patch: running "LC_ALL=cs_CZ.UTF-8 bash"
  with "LC_ALL=cs_CZ.ISO-8859-2" in .bashrc with this patch will make readline
  use UTF-8, even though it should not.
  This is the idea of bug #74701; this patch would just "fix" it for LC_CTYPE
  (only if originally set to C and POSIX) inside readline, but the place this
  needs to be fixed at (for all categories) is bash itself. See bug #74701 for
  POSIX citation.
  a) the calling program does not have its own environment (not a shell,...):
     the patch is not needed, libc does the right thing. If the program works
     with characters, it should have done setlocale (LC_CTYPE, "") on its own
     anyway (I consider it bad design for readline to modify LC_CTYPE locale
     setting (global state affecting the entire application) with no mention in
     the manual) but this is for readline maintainer to decide (that's why
     bash-2.05b-readline-init.patch has not been reported in a separate
     bug for the 'readline' package)).
  b) the calling program has its own environment (not accessible using
     getenv ()): it should under regular circumstances call setlocale () on its
     own. If it does not, then the problem with bash-2.05b-LC_CTYPE.patch
     occurrs here too.

And BTW, special casing C and POSIX simply cannot be right, because C and POSIX
are just as good and just as valid settings as anything else. If the parsing
of LC_ALL/LC_CTYPE/LANG in the patches makes sense, then it must make sense
even when current setting is not C/POSIX. If it doesn't make sense in that case,
it can't make sense in general.

Comment 21 Leonid Kanter 2002-10-17 10:13:32 UTC
if LC_CTYPE environment is set, bash must initialise its LC_CTYPE according to
environment variable, if it is not set - LC_ALL and LANG must also be checked
(like in bash-2.05b-LC_CTYPE.patch). I verified this patch in ru_RU.UTF8 locale
with russian utf-8 keyboard and everything works OK. Actually after fresh RH8
installation with Russian as default only LANG=ru_RU.UTF-8 is set.

Comment 22 Miloslav Trmac 2002-10-17 10:19:37 UTC
leon@geon.donetsk.ua: the patch works for the usual way of using locales
(you have exactly one you want to use), but is wrong generally. And BTW,
the order is LC_ALL, LC_CTYPE, LANG (in bash all from the internal shell
environment), not LC_CTYPE from outside, LC_ALL, LANG, as you seem to

Comment 23 Need Real Name 2002-10-17 12:58:41 UTC
Ops! I did not see path attached to bug #74701. I agree, patch for this bug 
with a path patch attached to bug #74701 (if applied both) is better that my 
path (patches). 
You right. Thanks.

Comment 24 Milan Kerslager 2002-10-18 10:17:36 UTC
Anybody who want to test bash-2.05b-readline-init.patch (#79725) feel free to 
download signed RPMS from ftp://ftp.pslib.cz/pub/users/Milan.Kerslager/RedHat-
8.0/RPMS/. After 12 hours there will be better connectivity (we have only 
10Mbps) on ftp://ftp.linux.cz/pub/linux/people/milan_kerslager/RedHat-8.0/RPMS/.
RPM has a patch from mitr@volny.cz.

It seems that this patch works. Many thanx to mitr.

Comment 25 Tim Waugh 2002-10-18 11:24:05 UTC
Fixed package is bash-2.05b-7.

Comment 26 Tim Waugh 2003-01-10 19:20:59 UTC
*** Bug 81553 has been marked as a duplicate of this bug. ***

Comment 27 Tim Waugh 2003-06-23 14:52:20 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


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