On 11/18/17 3:45 PM, Egmont Koblinger wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > Hi, > > Type a command (such as "echo asdfgh....") that just reaches the right edge > of the terminal (the cursor wraps to the next line) and execute it. > > Then, do any of these: > - double click on the last word of the command, or the first word of its > output, > - copy-paste across this line boundary to a graphical text editor, > - resize the terminal horizontally if it supports rewrap-on-resize (such > as gnome-terminal or urxvt). > > With a simple prompt such as PS1='\u@\h $ ' the result is as expected: > - double-click highlighting stops at that line boundary, > - copy-pasting reveals that there's an explicit newline there, > - rewrap on resize does what's expected. > > Running 'script' reveals that the cursor is actually moved up, then to the > right by 79 columns, the last letter of the command is repainted and an > explicit newline is added. > > Let's do the same with a colored prompt, e.g. PS1='\[\e[33m\]\u@\h > $\[\e[m\] ' > - double clicking selects across the line boundary, > - copy-pasting doesn't insert an explicit linebreak, > - rewrap on resize does silly things. > > According to 'script', the cursor is moved upwards and then immediately a > newline is printed to move it back. This, at least in some popular/standard > terminal emulators I've tried now (xterm, urxvt, gnome-terminal) does not > cause that line to be terminated with a hard newline. > > Could bash (readline?) please perform the "magic" of reprinting the last > character followed by an explicit newline, even in case of more complex > prompts?
Yes. Thanks for the report and the reproducible test case. This happens in _rl_update_final(), which needs to be updated to deal with a prompt containing invisible characters in this special case. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/