A bash irritation: mutable history
Here's one of those little things that irritate me about bash,
or more specifically its command line editing: its command history
is (sometimes) mutable. Under at least some circumstances, you can
overwrite a command that is in your history by going back to it (with
search or cursor up) and editing it again. When you do this, the old
version of the command is gone permanently; if you cursor back to it
again, you see your freshly edited version.
(This doesn't seem to happen all of the time or on all of the machines I
use bash on. So far I haven't had the patience to track down exactly
what's going on.)
My mental model of shell history is that the past
is immutable because it is, after all, the past; editing a past command
should just result in a new command that just looks a lot like the old
one. To have a sometimes mutable command history makes me nervous and
twitchy; among other things, that old command may be the only version
where I had something working (and I am editing it to try to improve
things, which may or may not be successful).
I do have some sympathies with the mutable command history crowd.
If you think of the command history as basically an edit buffer,
it's more natural to change things in place, and even if you don't
there are a bunch of interesting decisions (and painful programming)
to do to make things come out right.
(Thinking about some torture test scenarios, I think you need to pretend
that you have a mutable edit buffer and then undo all of the mutations
at certain trigger events and insert any new command line at the end of
the history. I maintain that one such trigger event should be clearing
the entire line, however it happens.)