Bug 74925

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
becomes messed.

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 
cause. 
 
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.

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

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

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

corwin.ru: 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
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
follows:
First we set LC_CTYPE category in value defined by environment variables (call
setlocale(LC_CTYPE,"")).
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

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

corwin.ru: mitr 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 corwin.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.
readline-4.3-LC_CTYPE.patch:
  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.

leon.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
suggest.

twaugh:  
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). 
 
mitr: 
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 mitr.

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.

http://rhn.redhat.com/errata/RHBA-2003-140.html