[PATCH] operate-and-get-next skips command after a multi-line command

[Greg Price]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux dark-matter 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1
(2020-01-26) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 3
Release Status: release

Description:

  When the function operate-and-get-next (C-o) is used on a multi-line
  command, if the history is full, the next prompt shows not the next
  command but the one after that.

Repeat-By:

  0. If your history is full in your normal shell session (i.e., it
  already contains $HISTSIZE entries), just start from step 1.  Or,
  start a fresh shell with "HISTFILE= HISTSIZE=4 bash --norc -i".

  1. Run the following three commands:

  echo 'a
  b'
  echo c
  echo d

  2. Then go up three places in the history to the two-line echo, and
  hit C-o.

  3. Observe that your next prompt is prefilled with "echo d", not
  "echo c".

Fix:

  The bug appears to be caused by the extra logic that was added to
  set_saved_history to fix this previous bug:

    https://lists.gnu.org/archive/html/bug-bash/2011-09/msg00050.html

  Removing that logic fixes this bug, but naturally reintroduces that one.

  I've attached a patch that fixes this bug without reintroducing the
  old one, and as a bonus the code gets a bit simpler.

  The idea of the patch is that for communicating from
  operate_and_get_next to set_saved_history the information of where
  in the history we want to be, instead of storing a physical offset
  like "where_history ()", we store a logical offset like
  "where_history () + history_base". This allows us to not worry about
  deducing whether the history got shuffled or not, because by design
  the logical offset of a given entry isn't affected when that
  happens.

  The patch also contains tests for both the previous bug (which
  occurs when the multi-line command was read from $HISTFILE) and the
  present one (which occurs when it was entered into the current shell
  session directly).

Thanks,
Greg

0001-Fix-operate-and-get-next-skipping-command-after-a-mu.patch
Description: Text Data