Terminal Prompt line wrap not working (Bash version 5.0.17(1)-release)

[Sumit Saini]

I've reported the issue on the bash bug tracker, with a short video showing the issue: https://savannah.gnu.org/support/index.php?110543

I hope that's the right place to report it. Readline website says it's developed alongside bash and the maintainer is the same person. Readline doesn't have a bug tracker.

Thank you very much for reporting the issue.

[xenopeek]

Somebody has posted a workaround you can try: https://savannah.gnu.org/support/index. ... 3#comment1

[rene]

Thanks for noting, but, well, yeah; not a fix.

[rene]

Just now revisited that report. The Kummer part all seems besides the point -- but do you understand what it is that Chet Ramey said there? As far as can tell he's saying that it's not a readline issue. Personally I would feel that every terminal emulator making for the same symptom and previous versions of bash/readline not having this issue would indicate otherwise.

[xenopeek]

No, I think he agrees it's a bug:

Readline keeps an array of prompt string offsets where it has to wrap the prompt to a new screen line. What's clear is that this needs to be updated upon receipt of a SIGWINCH if the screen width is less than the visible prompt length.

That's internal to readline, I assume he means some logic should be added to readline to do the above. As he goes on in the comment to explain, if the prompt offsets aren't updated in the readline array when the window is resized to smaller than the prompt is wide then readline incorrectly assume what it's position in the window is and will reprint the prompt without (partially) erasing the previous prompt as normally happens. It looks like it's printing the prompt multiple times but what actually happens is that it doesn't fully erase the previous prompt as it should.

[rene]

Mmm. Well, fair enough I suppose. I am/was reading it as "what's clear is that we/readline need to do [foo] --- which we are doing --- so Not Our Problem".

[rene]

No; your interpretation was right: https://git.savannah.gnu.org/cgit/bash. ... ed0fa95530

[xenopeek]

Nice to know Chet was that fast with a fix!

[rene]

That commit is on the -devel branch by the way; no idea how/by-when it's going to make its way down. But, yes, good to see.

[xenopeek]

That commit is on the -devel branch by the way; no idea how/by-when it's going to make its way down. But, yes, good to see.

I built the -devel branch to test it; it has improved the situation a lot but doesn't solve it. At least not on Gnome Terminal. It looks to be entirely solved on Alacritty. So some difference between terminals.

On Gnome Terminal it behaves as such:
- when slowly resizing the window, the issue does not occur
- very fast resizing of the window the issue does still occur but if you size the window up again (where it is wider than the prompt) it fully recovers and all the erroneous printed prompts go away

Because it behaves differently between terminals (with the fix) the developer blames the terminal for the remaining issue; that there is no way for readline to know exactly what the position of the cursor is when the window is resized. dash doesn't have the same issue, nor does bash 4.4, so it leaves me a bit confounded. For now I'll leave it alone and will retest once the patch is in bash stable.

[rene]

As far as I can see it's in fact still completely busted when using xfce4-terminal. Also just now build that -devel branch; fast or slow, it completely screws up when the terminal resizes to under prompt length and does not, I'd say, "recover" when resizing back. Did nothing specific to build; just

Code: Select all

$ git clone https://git.savannah.gnu.org/git/bash.git
$ cd bash
$ git checkout devel
$ ./configure; make; make install
$ xfce4-terminal -e /usr/local/bin/bash

Did you do something more involved?

[xenopeek]

Try replacing ./configure with ./configure --prefix="/usr" --enable-readline --with-curses to build bash with readline, so not use your system's readline. Because the bug is in that.

I tested with xfce4-terminal and for me at least the bug is improved. It can still be triggered, and sometimes it can't recover from the erroneous prompt. But it's much harder to fill the entire terminal window with the prompt than it was before.

[rene]

I had verified that lib/readline was in fact getting built (and it's for bash seemingly linked statically) but had not noticed --with-curses to be needed; yes, that seems to make the difference for me; with that and the bash -devel branch, the issue is also for me and with xfce4-terminal as you describe.