mailing list for the moment.
On Fri, 8 Dec 2023 at 16:54, Richard Stallman <
rms@gnu.org> wrote:
> > If two different shells will try to write history into one single file,
> > are they doomed to give bad results, one way or another...
> Not necessarily. If both shells use a single write() syscall on an
> O_APPEND file, they should work as expected to my awareness.
We are miscommunicating. The way you expect it to work is, in my
opinion, a bad result -- various histories interspersed.
It seems to me that the crucial thing is for each Bash process
to have its own separate history.
Do you think that behavior would be bad?
In my opinion, if I wanted to search for a command I'd previously run that
wasn't in my current bash shell history, how would the respective histories be created?
Would it involve .bash_history.${PID}, or would it involve
.bash_history.${CURRENT_TIMESTAMP} (whatever form that took),
or some other combination?
In each case, bash can already look up its own history, but when a new Bash shell is
started, just which history file is it going to load if there are multiple bash history files
saved to disk? The latest by ${CURRENT_TIMESTAMP}? The highest ${PID}?
And where will subsequent history be written to? A new ${PID} file?
People who run multiple shells in parallel are probably well aware of this now, and I expect that is why decisions were made way back when, to support one history file. The only real argument is whether that history gets erased when a current bash shell closes out and saves its own history over the top (sort of handled by histappend, but not entirely.)
> If a bash process decides to rotate the history file as a result of
> HISTSIZE, and another bash process decides to do the same, one of their
> new history entries would be lost due to the other one overriding it.
> This would be a bug.
Only if they share one single history file. If each has its own
history file, each can handle it as if it were your only Bash process.
I must admit to having thought that histories could be stored in a sqlite3 database,
that way rotation of expired entries (date or number of lines) could be handled by the
database itself. However, this means yet another dependency added to the chain
where you might not have wished one. And in addition, the licence that sqlite3 is provided
under is not a GNU licence, it's one of those licences that pretty much says
"We donate this to the public at large" (my summary, not theirs).
Another disadvantage for sqlite as a dependency, is that it's not the simplest solution
feasible. It is darn quick though, and its development is certainly current and ongoing.
One advantage to making the history as a single file (flat or database) is to make
searching easier, but that's also its Achilles heel when you want to rotate the file if you're running
multiple bash shells.
Regards, brickviking