Red Hat Bugzilla – Bug 978080
ssh seems to mishandle unicode characters > 1b when editing CLI
Last modified: 2013-07-19 11:23:22 EDT
Description of problem:
when connected with RHEL 6 ssh to any host (localhost, remote F19 openssh/bash, remote OpenWRT dropbear/ash), terminal misbehaves when editing CLIs that contain 2 byte unicode characters - when the cursor is to the right of such character and you move left, the cursor gets in the middle of the character instead of left to it. In some remote systems (F19 with tmux), even some whitespace is inserted to the right of the characters...
Given that all the remote systems misbehave the same, local (X) terminal works ok, I suspect ssh client as the culprit
The system locale is cs_CZ.UTF-8
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. connect with ssh to some host
2. paste this command to the terminal, hit enter:
echo -n '' | hexdump
3. hit up arrow
4. paste 'š' character inside the apostrophes, hit enter
5. hit up arrow
6. move left to get the cursor right right of 'š' character, ie 'š|' (pipe sign is placeholder for the cursor)
7. move one more character to the right
8. paste 'š' character
9. hit enter again
4. you can see output like this:
depending on your architecture
8. you can notice that something goes wrong with the CLI
you see output like:
0000000 c5c5 a1a1
meaning that the second 'š' got pasted right into middle of first 'š'
4. the same
8. nothing gets wrong when editing cli - i.e.:
0000000 a1c5 a1c5
0000000 c5a1 c5a1
when you hop from the beginning to the end and vice versa in plain shell (no tmux), the PS1 prompt gets eaten with each hop to the left
I'm not able to reproduce your issue. What kind of xterminal do you use? Is it on rhel-6 or are you connected to rhel-6 via ssh? Are you on a physical console? Or is it a virtual and do you use vnc? spice?
gnome-terminal on RHEL6.
still can't reproduce. Random idea: how does your prompt PS1 or so looks like?
If you can provide more information how to reproduce this issue, please attach them and reopen this bug.
Created attachment 775801 [details]
The observed behaviour was caused by setting LC_ALL to C, so there is no bug on ssh part indeed, just bogus configuration.