Package: bash Version: 5.0-4 Severity: normal Dear Maintainer,
Apologies in advance. I don't know the proper terminology, so this might be a known issue. I'll just describe what I expect to happen and what actually happens on Buster. Let's say I have a .bash_history file containing the following two lines (for simplicity; it happens regardless of how many lines): ls ps Let's assume I am using Debian Stretch and I login to a new bash shell (v4.4.12) and am looking at an empty prompt. I invoke the previous-history command (C-p or up arrow) and see `ps` on the prompt. I invoke it again and see `ls` on the prompt. I invoke it a third time and the prompt does not change (still displaying `ls`) except the terminal bell dings because I've hit the beginning of the history file. Now, I invoke the `next-history` command (C-n or down arrow) and the prompt changes to `ps`. I invoke it again, and the prompt returns to the empty prompt, because I am now at the end of the history. I can move back and forth through history many times, and get the exact same results each time. Now, exact same scenario, except I am now using Debian Buster which comes with bash v5.0.3. From an empty prompt, I invoke the previous-history command (C-p or up arrow) and see `ps` on the prompt. I invoke it again and see `ls` on the prompt. I invoke it a third time, but this time, the prompt changes to an empty prompt. (At this point, I'm past the beginning of the history file. Subsequent experimentation shows that I am actually displaying the contents of the current prompt, which in this case is empty.) Now, I invoke the `next-history` command (C-n or down arrow) and the prompt changes to `ps`, seemingly skipping `ls`. I invoke it again, and the prompt remains on `ps`. I have to Ctrl-C or Ctrl-U to get back to an empty prompt. Further experimentation with moving back and forth through history reveals that the history given by previous-history and next- history becomes increasingly corrupted each time you move past the beginning of history. I've tried this on bullseye (bash v5.0.11) and the corruption happens there as well. I also tried it on OSX running Homebrew and bash v5.0.16, and the issue did not present on that platform. I'm not sure if this means it's a Debian- specific issue, or if the issue was fixed in at some point after 5.0.11. This feels like an off-by-one type issue in a circular array, but I am totally unfamiliar with the bash code base, so it'll be a while before I could really dig into it, and would appreciate any pointers if someone has an insight into where this is happening. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bash depends on: ii base-files 10.3+deb10u3 ii debianutils 4.8.6.1 ii libc6 2.28-10 ii libtinfo6 6.1+20181013-2+deb10u2 Versions of packages bash recommends: ii bash-completion 1:2.8-6 Versions of packages bash suggests: pn bash-doc <none> -- no debconf information
