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
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?
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
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 = £ = £
The problem is on text console (tty).
Happens with us too, fi-latin1.
Probably a duplicate (side-effect) of bug #74701.
Isn't this a duplicate of bug 68313? Seems like that one never was properly fixed.
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.
#68313 is not a public bugreport and has been already closed. So I decided not
to reopen it.
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.
Created attachment 79725 [details]
Patch to make readline init from bash variables instead of original environment
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
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
*** Bug 71684 has been marked as a duplicate of this bug. ***
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")
firstname.lastname@example.org: Did you see the patch already attach to bug #74701?
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
functions incorrectly work: mbrlen(), mbrtowc() and etc. (incorrectly determined
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
is defined, then set LC_CTYPE category.
In this case the first instance of bash also uses LC_CTYPE category defined by
(or ~/.i18n )and works fine with UTF-8 codings
The similar patch needs to be applied and to readline-4.3-3 package
Created attachment 80684 [details]
Similar bash-2.05b-LC_CTYPE.patch only for readline-4.3-3 package
email@example.com: firstname.lastname@example.org 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?
I believe the patches from email@example.com 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
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.
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.
firstname.lastname@example.org: 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
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
You right. Thanks.
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 email@example.com.
It seems that this patch works. Many thanx to mitr.
Fixed package is bash-2.05b-7.
*** Bug 81553 has been marked as a duplicate of this bug. ***
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.