On 2/10/24 8:16 AM, Flightkick wrote:
Bash Version: 5.2 Patch Level: 26 Release Status: releaseDescription: Let me preface this bug report by stating that I am not entirely sure as to whether this issue is caused by bash, or by another component related to the bash ecosystem. I hope that someone more knowledgeable in this area may help to direct this report to the right maintainers if this is not the correct place. The issue I'm experiencing occurs when a large command (one which exceeds the terminal size x*y, with wrapping enabled instead of horizontal paging), is present on the bash history. If the user then cycles through the history or lands on that command by Ctrl+R search, the terminal then fails to render the prompt correctly when cycling to another (shorter) entry. Instead showing blank spaces up until the cursor position. With real-life cases, navigation through history and moving the caret results in more glitchy representation of the selected command. To work around this issue, one could hit Ctrl+L in order to clear the terminal and re-render the prompt. But it's ultimately not a great experience when working with such large commands present in the history.
The issue is that having displayed the complete line and exceeded the
physical screen boundaries, readline doesn't know exactly where it is. It
needs to know the physical cursor position to do redisplay, and having
the terminal window scroll underneath it prevents that.
There are changes already in the readline devel branch to deal with this
in some cases, but readline will never be a screen editor, and will deal
with very long lines as best it can, which will probably not be perfect.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
