Japanese Character Encoding Bug

[dupingping]

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.

[dupingping (dupingping86)]

I saw this bug.

[dupingping (dupingping86)]

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.

[Egmont Koblinger (egmont-gmail)]

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"

[dupingping (dupingping86)]

The values are as following.

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

[Egmont Koblinger (egmont-gmail)]

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)]

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.

[dupingping (dupingping86)]

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

[Egmont Koblinger (egmont-gmail)]

"\[" 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)]

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.

[Egmont Koblinger (egmont-gmail)]

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)]

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

[Egmont Koblinger (egmont-gmail)]

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)]

It's fixed since Wily.