Japanese Character Encoding Bug

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

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\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi

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

Revision history for this message
dupingping (dupingping86) wrote :

I saw this bug.

Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Changed in gnome-terminal (Ubuntu):
status: Confirmed → New
Revision history for this message
dupingping (dupingping86) wrote :

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

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

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

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

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

Revision history for this message
dupingping (dupingping86) wrote :

The values are as following.

$ echo $PS1
${debian_chroot:+($debian_chroot)}\u@\h:\w\$
$ echo $PROMPT_COMMAND
pwd>&8;kill -STOP $$

Revision history for this message
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?

Revision history for this message
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\$
$ echo $PROMPT_COMMAND

That's all for the commands.

Revision history for this message
dupingping (dupingping86) wrote :

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

Revision history for this message
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).

Revision history for this message
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.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

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.

Revision history for this message
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?

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

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.

Revision history for this message
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