Please continue to CC: me on this thread, as I'm no longer part of the
emacs-devel
mailing list for the moment.
On Fri, 8 Dec 2023 at 16:54, Richard Stallman <r...@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
---
via emacs-tangents mailing list
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)
