Thank you!! Why on earth isn't that the default. It always seemed weird that with multiple bash windows open, the commands from most of them weren't added to the history.

I often have three or more terminals open, doing different tasks in each; I also often have cycles of work where I'll repeat the last three commands again (three up-arrows and a return). This breaks if one terminal's commands get inserted into another terminal's history.

Comment from the author:

"Ted, the change I suggest doesn't affect the independence of your sessions as you suggest. Each shell maintains a unique history in memory so modifying the history file has no affect on running terminals. The only time the history file is read is when you start a new terminal. I recommend you try my suggestion. Really, all I am doing is eliminating the race condition that causes the bash history file to have inconsistent data.

Thanks for the feedback."

Exactly this.

If you do want to load the history persisted from other shells into the current one, all you have to do (if memory serves) is:

    $ history -r

My solution is I immediately record the commands, but do not load them. That way new terminals get all the history, but old terminals keep their flow.

But if you go back later, the chains of commands from different terminals are interlaced right?

To some degree; it depends on the amount of multitasking. I mainly care about which commands in which order when I'm looking at recent commands from that terminal; otherwise I use C-r.

My guesses are that it's on-close so you can follow the per-shell history slightly easier (rather than it being interleaved from multiple shells?), or reducing disk writes?

They don’t interlace which can be nice

It is very useful just be careful when switching between shells and hitting the up arrow to get the previous command, as you may get something from another shell.

That will only happen if PROMPT_COMMAND also contains "history -c; history -r", right? "history -a" just saves it, but "history -c; history -r" clears memory history and reloads from disk.

Yes, that's correct. I overlooked that detail while reading the link on a phone, where the text is quite small.

Meta question : do you keep the archive.org link of the article in your favorite or did you manually look up the link before posting? Or maybe an extension that does that automatically?

for zsh

    setopt inc_append_history

I have used that for years, but there are downsides to the approach as well.

So, you revisit a window, and you want to start from where you left, but now, you might maybe wade through 100's of commands before you get back to that point in time. There are fixes for this too of course, my point is, that it doesn't come without side effects, and that is maybe why it isn't set as default behaviour. At least in a pre 'fzf/atuin/smenu' world.

I prefer smenu's history search, even if I consider myself a heavy fzf user.

FWIW I get a 503 on that URL. Any chance someone can give me that magic one-liner?

Looks like it is still down - but see eg: https://askubuntu.com/questions/67283/is-it-possible-to-make...

To wit:

> It says to put those commands in the .bashrc config:

    shopt -s histappend
    PROMPT_COMMAND="history -a;$PROMPT_COMMAND"

> The first command changes the history file mode to append and the second configures the history -a command to be run at each shell prompt. The -a option makes history immediately write the current/new lines to the history file.

I used to have something like this set up on my Linux laptop - the downside is that seperate shell/terminals/windows/tabs don't keep seperate history - so if you eg start a server in shell one (rails s), start editor in two - then go back to one and ctrl-c out - up arrow will now give you "vim" not "rails s".

The problem compounds if you ping, or curl in another shell etc.

Not sure what that link had as it's dead for me as well but...

PROMPT_COMMAND='history -a'

Has always worked for me. Goes in your .bashrc from the FM

PROMPT_COMMAND ¶ If this variable is set, and is an array, the value of each set element is interpreted as a command to execute before printing the primary prompt ($PS1). If this is set but not an array variable, its value is used as a command to execute instead.

I did that once (or it might have been something similar with the same effect, don't remember) and after a while it made my terminals super slow.

Oh wow thank you for this.