I've gradually come up with a way too elaborate system for maintaining and sharing bash histories locally. I run tmux with several long-running bash prompts and

I've gradually come up with a way too elaborate system for maintaining and sharing bash histories locally. I run tmux with several long-running bash prompts and not only I want to append each shell's history into a log incrementally but also to share history between the running shells. I have a function as my prompt command that does: - dump the current in-memory history into a separate logfile every few minutes timestamped (using HISTTIMEFORMAT) - clear the local in-memory history and reload in-memory history from unique history lines from all stored log files, using the most recent timestamp on each Once there are more than N log files, one of the shells does a similar uniquefying compation step for N log files and writes the output into one new log file. It uses 'mv' to do the compation atomically by moving the affected log files away into a temporary directory for compaction. If other shells were to update their logs during the compaction those additions would just be saved as normal and compacted in the next cycle. There are always duplicate history lines in the logs to keep things fast so there's no chance for a race condition: no command line in the history can get accidentally deleted and any duplicates are just removed during reading. As a final step I atomically copy the latest compacted history into .bash_history as a backup. The real data lives in my logs anyway but a single .bash_history is easier to backup: it might be a few lines short but it's always mostly up-to-date. Looking back at this, I reckon the current Bash history implementation surely can't be ideal.