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.
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?
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.
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?
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.
> 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.
yesenadam|2 years ago
dtgriscom|2 years ago
noxvilleza|2 years ago
usefulcat|2 years ago
CuteDepravity|2 years ago
dbtc|2 years ago
McUsr|2 years ago
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.
RustyRussell|2 years ago
e12e|2 years ago
To wit:
> It says to put those commands in the .bashrc config:
> 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.
jdhendrickson|2 years ago
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.
CorrectHorseBat|2 years ago
drekipus|2 years ago
Tcepsa|2 years ago