[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Greg Price
Subject: [PATCH] operate-and-get-next skips command after a multi-line command
Date: Sun, 19 Apr 2020 16:58:45 -0700

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


  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.


  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
  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".


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


  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

  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).


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]