Large command in bash history breaks rendering

[Flightkick]

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):
  `a` (... 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).

Re: Slow history load with some values of HISTSIZE

[Casey Johnson]

Thanks! I'm happy to help.

From: alex xmb sw ratchev 
Sent: Friday, February 9, 2024 9:13 PM
To: Chester Ramey 
Cc: Casey Johnson ; bug-bash 
Subject: Re: Slow history load with some values of HISTSIZE



On Sat, Feb 10, 2024, 03:06 Chet Ramey 
mailto:chet.ra...@case.edu>> wrote:
On 2/3/24 3:29 PM, Casey Johnson wrote:

> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
>
> The current implementation of the command history takes a long time to load
> a large HISTFILE when history is stifled.  This is because there is a
> memmove() for every line of HISTFILE once HISTSIZE lines have been loaded.
> If N is the number of lines in HISTFILE then the cost of the memmoves ends
> up being something like (N - HISTSIZE) * HISTSIZE, peaking when HISTSIZE is
> roughly N/2.

Thanks for the report and the patch. I applied it with some tweaks and
saw a dramatic performance improvement for very large history files (I
tested with one that was about 69 entries) where HISTSIZE is
significantly smaller (I tested with HISTSIZE=10): from around 11
seconds to less than 0.3 seconds.

++ speed optimization

greets ++

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.edu
http://tiswww.cwru.edu/~chet/

internal error

[Frank Heckenbach]

% ./bash -c "set -e; f() { eval false; }; f"
./bash: line 1: pop_var_context: head of shell_variables not a function context

Might be related to
https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00073.html,
but still present in 5.2.21.