I was bitten several times by losing bash history on a crash etc, and found useful article http://briancarper.net/blog/248/keeping-bash-history-in-sync-on-disk-and-between-multiple-terminals I noticed we already use "shopts -s histappend" (bug #139609), and the further improvement I'd recommend is something like this: PROMPT_COMMAND="${PROMPT_COMMAND};history -a" By the way, also note bug #223641 about cleaning up PROMPT_COMMAND handling.
should be all set now in the tree; thanks for the report! Commit message: Add history -a to PROMPT_COMMAND http://sources.gentoo.org/app-shells/bash/bash-4.3_p33-r2.ebuild?rev=1.1 http://sources.gentoo.org/app-shells/bash/files/bashrc-r2?rev=1.1
I don't want to write to disk everytime I press enter. Yuck. Also, like many others, I rely on the history being written to disk in the order commands were typed *per terminal*, not interlaced. Please revert this surprising behavior change.
I also really don't appreciate the extra disk writes. This is bizarre behavior. The comment in the bashrc file even makes this clear: # Save each command to the history file as it's executed. #517342 # This does mean sessions get interleaved when reading later on, but this # way the history is always up to date. History is not synced across live # sessions though; that is what `history -n` does. I understand if some people want this, but this certainly should *not* be default. And changing it silently for all the people who rely on the defaults is not very nice at all.
This can also bite you when a machine is low on memory, PROMPT_COMMAND has a lot more overhead a can efectively lock you out. Happened to me more then once… I agree this feature is handy to have around, but is not suited to be default.
Yes, indeed, this causes some serious issues in machine failure modes -- disks failing, memory pressure, etc -- all emergency situations in which having a usable prompt could really save the day. This change makes that impossible.
(In reply to Jason A. Donenfeld from comment #3) extra disk writes isn't a compelling reason. bash isn't running `sync` after every write here. it's pretty rare that your disk is actually idle to the point where this is causing noticeable overhead, especially when this kicks in only when you're actively doing things on the system. your disk will cope just fine. wrt "doing it silently", that's both entirely wrong (read the ChangeLog) and a fairly invalid argument. the defaults in a lot of packages change (bash included). you're only complaining here because you dislike the new default. sorry, but every proposal isn't going to go by you for approval. (In reply to Hynek "radon" Fabian from comment #4) the default profile has been using PROMPT_COMMAND for almost a decade and no one has complained. i don't know what kind of overhead/memory pressure you think it causes, but i highly doubt it. `history` itself is a builtin, and the -a option merely causes an append open, a write, and a close. (In reply to Jason A. Donenfeld from comment #5) memory pressure is bs and you have no data to back that up. fortunately for you though, being able to cope with a failing disk in an emergency i do find compelling. i have seen situations where writes go to lunch and never come back, but otherwise the shell was able to continue forking/running programs.
Adding history-a to the PROMPT_COMMAND is clearly one of the millions of "clever hacks" spread across blogs and commenters on the internet. And indeed it's a very nice "trick" for people who explicitly want that functionality. But it does not belong in the default bashrc, and neither does the other millions of "clever hacks" from the blogosphere. The history-a hack is particularly nasty in certain situations, and is definitely unwelcome.
Just one man's opinion, but this is a bad default. I went ahead and removed it locally, but would strongly suggest reverting this commit so that others are not subjected to this unnecessary change. I do believe it's a good feature, but it should remain opt-in as it was before. Interleaved sessions in the history by default now, very unfortunate.
(In reply to Jason A. Donenfeld from comment #7) i don't know what point you're trying to make here. i already said i planned on reverting the default based on recovery situation. if i didn't plan on reverting things, i would have closed the bug already.
It's been about six weeks; is there any status on this change being reverted as previously agreed upon?
(In reply to Greg Kubaryk from comment #10) the bug tracks the current status pushed now since i have a version bump also going in: http://sources.gentoo.org/app-shells/bash/files/bashrc-r2?r1=1.1&r2=1.2
