When I have some output without linebreak at the end in front of my bash prompt and enter a long command that wraps to the next line, I can get back into the first line but I can't return to the second line, and trying to do so completely confuses cursor positioning; from then on the cursor will be displayed in a different position than bash thinks it is. Occurs only in UTF-8 locale. Reproducible: Always Steps to Reproduce: 1. LC_CTYPE="en_US.utf8" urxvt 2. echo -n aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3. enter some random words 4. press Home or Ctrl+A 5. press End or Ctrl+E or hold down the right cursor key 6. hold down the left arrow key 7. enter some more words 8. press Ctrl+L 9. press Home or Ctrl+A Actual Results: 5. the cursor will not move past the line wrap 6. the cursor will move into the prompt and maybe even into the text from 1. 7. the text will be displayed where the cursor is, but buffered somewhere else 8. the redrawn screen will show the buffered text 9. the cursor position is still wrong, this time too far to the right Expected Results: 5. cursor position crossing the line wrap in both directions 6. cursor should always be displayed where bash thinks it is 7. text should always be displayed where bash inserts it 9. redrawing the screen should correct cursor position as well if possible I'm not sure whose bug this is. bash? readline? rxvt-unicode? ncurses?
Cannot reproduce this at all; which versions you have installed? app-shells/bash-3.2_p17-r1 sys-libs/readline-5.2_p4 x11-terms/rxvt-unicode-8.2
(In reply to comment #1) > Cannot reproduce this at all; Try this instead of step 1 above: env -i DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY LC_CTYPE="en_US.utf8" \ PS1='\[\033[34m\]\u@\h:\w \$\[\033[00m\] ' urxvt -name urxvt-debug It seems that the use of escape sequences in PS1 has some influence. Also make sure that "locale -a | grep en_US.utf8" lists that locale. > which versions you have installed? I had app-shells/bash-3.2_p17 but updating to -r1 didn't help. readline and rxvt-unicode I've got the same, although I even tried rxvt-unicode-8.3 (bump requested in bug 188268) but that didn't make a difference either.
(In reply to comment #2) > Try this instead of step 1 above: No, no luck at all, behaves perfectly fine.
(In reply to comment #3) > No, no luck at all, behaves perfectly fine. That is really strange! I just added "-e bash --norc --noprofile" to the command line, but no luck there either. Now I really begin to believe it might be due to some compiler switches or some such. Question is again, which of these packages? Recompiling them all with probably lots of different settings feels like a lot of work. Will have to wait till next week at least.
Created attachment 128427 [details] Animation demonstrating the issue
Created attachment 128429 [details] Log of pty traffic for demo session This log displays all the traffic between the terminal and bash. Lines starting with > are output from bash, whereas lines starting with < (and indented) are input typed into the terminal window. This conversation was recorded in the same session as the attached GIF animation.
Created attachment 128430 [details, diff] Patch that allows logging of pty reads This patch was used to create the attached conversation log. It introduces a perl hook on_tt_read analogous to on_tt_write that receives the raw octets read from the child process. The included script can be run by passing the command line arguments "--perl-lib ${WORKDIR}/src/perl -pe mvgdbg". It will write a conversation log like the one attached to /tmp/mvgdbg.txt
you can retry with 3.2_p33 as it has some invisible byte fixes
(In reply to comment #8) > you can retry with 3.2_p33 as it has some invisible byte fixes Ctrl+L seems to work better now, so steps 8 and 9 are fixed now. The others remain.
Recently a bug was fixed in readline, that seems to be the cause of this problem (5.2_p13). See, if it's fixed.
Can anyone check if this bug still exists? I can't reproduce it. Thanks
its been a while since this bug got any significant updates and I can't reproduce it, so I'm closing it.
Sorry I haven't replied before. Still can reproduce this.
