Japanese Character Encoding Bug

I saw this bug.

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.

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"

The values are as following.

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

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

Can you reproduce outside of mc?

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.

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

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

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.

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.

It's fixed since Wily.