Japanese Character Encoding Bug

Bug #1514288 reported by dupingping on 2015-11-09
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-terminal (Ubuntu)

Bug Description

After I set the character encoding as to Japanese(ISO-2022-JP),
and then input "Enter",
The bash prompt is shown doubled.
In another encodings, This bug is not occurred.
I tested it on precise and trusty.
It related to PS1 variable of bashrc.
You can find following lines at /etc/skel/.bashrc or $HOME/.bashrc

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

In above lines, The second line is incompatible for Japanese Encoding mode.

dupingping (dupingping86) wrote :

I saw this bug.

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Changed in gnome-terminal (Ubuntu):
status: Confirmed → New
dupingping (dupingping86) wrote :

case "$TERM" in
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"

I found above lines at the .bashrc.
And the escape character, "\[\e]0;" does not work on Japanese(ISO-2022-JP) Encoding.

Egmont Koblinger (egmont-gmail) wrote :

Does setting a much simpler PS1 make the bug go away? E.g.

Can you please share the current values of PS1 and PROMPT_COMMAND?
echo "$PS1"

dupingping (dupingping86) wrote :

The values are as following.

$ echo $PS1
pwd>&8;kill -STOP $$

Egmont Koblinger (egmont-gmail) wrote :

You seem to be running midnight commander Do you turn off its panels and press Enter there?

Can you reproduce outside of mc?

dupingping (dupingping86) wrote :

yes, It was mc.
Following is not in mc.
$ echo $PS1
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$

That's all for the commands.

dupingping (dupingping86) wrote :

I think that Japanese ISO-2022-JP Encoding conflicts the escape string, "\[\e" with the terminfo, xterm.

Egmont Koblinger (egmont-gmail) wrote :

"\[" never makes it to the terminal, it's internal to bash.

 I can't reproduce in Wily. The underlying terminal code changed a lot, in fact, we removed all the special handling for iso-2022 (escape sequences within and such), it's now purely a charset handled by the iconv layer. This might have fixed it (or broke it in other ways).

dupingping (dupingping86) wrote :

Yes, It may be not appeared on normally.
Please copy /etc/skel/.bashrc in to your $HOME folder.
And then please open the gnome-terminal.
I think that then you can reproduce this bug.
I could not reproduce this bug in Wily, but it's difference in Precise and Trusty LTSs.
Can you help me so let me know about which pacakge is related to iso-2022 escape sequences?
Best Regards.

The actual relevant package is vte.

I'm not an Ubuntu developer, I'm a vte and gnome-terminal developer lurking around here. If it's fixed in Wily, I'm happy that it's no longer a bug in mainstream gnome-terminal. There's nothing I can do to backport the fix to older Ubuntus.

dupingping (dupingping86) wrote :

Yes, I understand.
And I'm a Ubuntu Member. Let me try to solve this problem for Ubuntu LTS versions.
Can you help me?

No, sorry, not.

It was a series of big patches heavily modifying the behavior. They're clearly not suitable to be backported to a stable distro. There's no self-contained tiny fix available for this problem. And since it's fixed in mainstream gnome-terminal, I have absolutely no interest in putting any effort into this.

You've just reported this bug towards trusty (1.5 years old) and precise (3.5 years old). I can't remember anyone ever reporting the same issue before, so it's apparently not an important one.

There are way more important vte issues in Ubuntu's bugtracker with one-line fixes that noone cares backporting.

It's fixed in Wily, and Xenial LTS is out in less than half a year.

Fixed packages for trusty are probably available from Gnome3 staging. Or you can use any other emulator as a workaruond for the time being.

And, anyways, iso2022 is a terrible encoding, and everybody should've switched to UTF-8 a long time ago.

dupingping (dupingping86) wrote :

It's fixed since Wily.

Changed in gnome-terminal (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions