On 11/25/25 1:59 PM, Christian Zuckschwerdt wrote:
the current version uses the same underlying functions when performing incremental and non-incremental searches to preserve modified history lines consistently.Thanks for the explanation. I sure am using line editing like a savage and I might need to update my „technique“, it sounds like this is a regression just to me and there is no bug to investigate?
Sorry it took so long to get back to this. Yes, I changed things so that behavior is more consistent between search modes. I guess that can be seen as a regression by people used to the old behavior.
Like shown, in some cases I get partial lines (or sometimes empty lines) added to the .bash_history -- I assumed the .bash_history is a record of commands executed? In other cases the running history loses recent entries when editing lines. I think this is the feature you are explaining, but here is an example: E.g. starting a shell with "echo hello" and "echo world" in .bash_history I can recall both using Up and Down keys. But pressing Ctrl-U on a recalled line (or Ctrl-K or Ctrl-C after editing) will seemingly remove it from the history. It is not available using Up or Down anymore. I can clear the whole history doing that.
Yes, you can edit history lines, and the edited lines exist in the in-
memory history, with undo lists that can be used to restore them. If you
have, say,
echo hello
echo world
echo a
history
in the history, you can move to a line (say, hello a) with ^P, or
^Rw, or some other history traversal mechanism, and `remove' it with ^U,
then move to another history entry, you will have
$ history
1 echo hello
2 echo world
3*
4 history
That third entry has an undo list that you can use to restore the
original contents. The `*' indicates it's an edited line. You can move
to that line, run C-_ (undo) or M-r (revert-line), and restore the
`echo a'.
All the search functions and history traversal functions behave
consistently like that.
Upon exiting the shell the .bash_history still has these entries however (and any additional commands executed).
Yes, it seems so. It's because the shell tries to write only the entries added during the current session when it exits. It leaves entries from a previous session (that it `inherited' from the history file) alone, even if they were edited. You can set the `revert-all-at-newline' readline variable if you want readline to go through and run the undo list for each history line that has one when it runs accept-line (usually bound to newline).
I expected the history to be somewhat persistent or immutable (if that makes sense?). I frequently use history entries as "templates“ to create new lines. But now recalling an entry and editing it will lose that history entry?
If you don't restore it. You can set the variable I mentioned above if you don't ever want to leave partially-edited entries in the history list.
My workaround is to use fzf (bound to Ctr-R) to recall entries as it leaves the original untouched, but it feels like a kludge.
If you edit a history line and then execute it, without using one of the
history traversal mechanisms to move away from that history line before
accepting it with a newline, readline restores the original version of
the history line you modified.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
