Re: bash strangeness with utf-8
Hi Benno,
Here is the output from "locale":
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=en_US.UTF-8
The following prompt is set in my .bashrc (but the same behavior happens
if I do not set it or set it to a simple string, so I don't think this
matters):
PS1="\[\033[33m\]\h-\u\[\033[36m\] [\w] (\!)\[\033[00m\] "
PROMPT_COMMAND is not set.
I have attached a script in which I caused the two cases I talked about
in my first mail. I started the script, and then:
1) hit up arrow (to get to previous command, which was "cd")
(cursor now at end, after "cd" - expected)
2) hit right arrow twice
(no visible change - cursor still at end - expected)
3) hit left arrow once
(cursor does not move - strange!)
4) hit left arrow again
(now cursor moves back one - should have moved back at step #3 above)
5) with cursor between "c" and "d" now, hit ctrl-k
("d" disappears - exptected)
6) hit right arrow repeatedly
(cursor moves back and forth (left & right) one char position
- first over "c", then after, then repeating - with each
right arrow hit - strange!)
7) hit down arrows to end of history, then hit ctrl-d to get out
of script
Hope the above is clear and that the script helps.
-Joe (lavajoe at gentoo)
Benno Schulenberg wrote:
> Joe Peterson wrote:
>> when using LAN=en_US.UTF-8 (anf we've verified same on
>> en_GB.UTF-8).
>
> Apart from LANG=en_US.UTF-8, what is the rest of your locale?
>
>> There are two cases I came up with. If you up-arrow through your
>> history, hit right-arrow (i.e. going "past" the end - even though
>> the cursor stops at the end), it takes 2 left-arrows to go back a
>> character (as if there were an extra character at the end).
>>
>> Case 2 can usually be invoked by going back a character or two,
>> hitting ctrl-k (to chop off the end of the line), and then
>> hitting right-arrow repeatedly. The cursor will oscillate back
>> and forth at the end of the line (well, I can almost always get
>> this to happen...).
>
> Cannot reproduce either case. Can you provide examples in the form
> of a typescript (using 'script')?
>
> Benno
>
>
bash_utf.script
Description: Binary data
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash strangeness with utf-8
Hmm, interesting. I thought that using "env | grep PROM" would show
PROMPT_COMMAND's value, but I guess not. Yes, I do have PROMPT_COMMAND
set, it appears. However, if I unset it (and even also 'export PS1="foo
"' to set PS1 to a simple string), the problem remains.
How best to debug this? tcsh and sh do not exhibit the problem, and it
only seems to happen on Gentoo/FreeBSD (not Linux).
-Joe
Benno Schulenberg wrote:
> Giraud wrote:
>> The following prompt is set in my .bashrc (but the same behavior
>> happens if I do not set it or set it to a simple string, so I
>> don't think this matters):
>>
>> PS1="\[\033[33m\]\h-\u\[\033[36m\] [\w] (\!)\[\033[00m\] "
>>
>> PROMPT_COMMAND is not set.
>
> Look at your typescript with vim. You'll see this gets printed:
>
>^[]0;[EMAIL PROTECTED]:~^G^[[?1034h
>
> before your prompt is printed:
>
>^[[33mcrater-joe^[[36m [~] (500)^[[00m
>
> Where is that first string coming from if not from PROMPT_COMMAND?
> It looks suspiciously similar to what Gentoo sets as prompt command
> in /etc/bash/bashrc. :) Except for this "^[[?1034h" at the end.
> Where is that coming from? It does strange things with the width of
> the terminal when I add it here to PS1. So when you get rid of it,
> things might work correctly again.
>
> Benno
>
>
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash strangeness with utf-8
Benno Schulenberg wrote: > Then look at a new typescript, and see if that strange 1034h is > still there. If yes, a simple 'set | grep 1034' might find the > variable that contains it. Nothing found doing this grep... As for doing a script, the "1034h" is indeed missing in the plain shell you suggest below, but the problem remains (see below). >> How best to debug this? tcsh and sh do not exhibit the problem, > > Aha. Then try 'env -i bash --noprofile --norc'. If that instance > of the shell doesn't exhibit the problem, then you know for sure > it's something in the environment. Initially, after entering this plain shell, the problem does not exist. However, a simple "export LANG='en_US.UTF-8'" resumes the problem faithfully. > If the problem remains even with an empty environment, try using an > empty ~/.inputrc or /etc/inputrc. These files do not exist on my system, so I tried without one and with an empty one. No change (problem still happens). Is there somewhere in the bash code I can put some debugging statements (or some way of logging) that you can suggest? Since I'm running Gentoo, altering the source to test is fairly simple. -Joe ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
