Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -flto=auto -g -D_GNU_SOURCE
-DRECYCLES_PIDS -Wall -g -Wuninitialized -Wextra -Wno-switch-enum
-Wno-unused-variable -Wno-unused-parameter -Wno-parentheses -ftree-loop-linear
-pipe -DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0
-DDEFAULT_LOADABLE_BUILTINS_PATH='/usr/lib64/bash'
uname output: Linux hephaestus 6.7.2-1-default #1 SMP PREEMPT_DYNAMIC Fri Jan
26 11:01:28 UTC 2024 (a52bf76) x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
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.
I managed to reproduce the behavior in freshly installed VM's on both
OpenSUSE Tumbleweed KDE with Konsole and Fedora GNOME with GNOME Terminal.
However, strangely enough I was not able to reproduce the behavior on either
ubuntu or opensuse/tumbleweed Docker containers running on my OpenSUSE
Tumbleweed host. I suspect that xterm or GNU Readline could be the differential
factor but I'm not familiar enough with the architecture to make any decisive
statements on that.
I *think* I was able to reproduce this behavior in both sh, bash and
fish. Although I am not sure if my tests on these shells were completely valid,
as I may not have been able to spawn a clean/standalone shell without inherited
environment variables or may have experienced influence from spawning a
subshell.
I originally opened a discussion on the OpenSUSE Tumbleweed forums,
which can be found here:
https://forums.opensuse.org/t/large-command-in-bash-history-breaks-rendering/172299
My host system info:
Operating System: openSUSE Tumbleweed 20240206
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.114.0
Qt Version: 5.15.12
Kernel Version: 6.7.2-1-default (64-bit)
Graphics Platform: Wayland
Repeat-By:
- Open the terminal
- Execute a very large dummy command (which should be larger than the
terminal size x*y, make sure wrapping is enabled instead of paging):
`aaaaaaaaaaaaa` (... repeat a's until the size exceeds your visible
area.)
- Run another command: `echo test`
- Press the UP arrow twice
- You should now have the aaa command visible. Notice that the cursor
is located at the end of the command. So the PS1 string/prompt shouldn’t be in
the visible area right now. (so far so good)
- Press the DOWN arrow once
- Notice that the cursor is located at the end of where it would be if
PS1 + ‘echo test’ would be rendered. But instead there’s only whitespace before
the cursor.
- Scroll up slightly and notice that ‘echo test’ has been appended to
the aaa characters.
- Press ENTER and notice that the echo command is correctly executed.
(Proves that this is issue is related to rendering).
