Re: [OT] Not clobbering bash history

["Arsen Arsenović" <arsen@aarsen.me>]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]


Richard Stallman <rms@gnu.org> writes:

>   > > Should we suggest that the Bash developer add a feature to handle this
>   > > case (multiple shells in parallel) the "right" way?  If many users
>   > > would like it, that could make it worth building in.
>
>   > That would be very nice.  This issue has almost been prolific enough to
>   > force me to switch shells.
>
> How about if you (or someone) write a description of the behavior you
> would like Bash to offer (at least as an option)?

Sure.

libhistory should, on recall attempt, try to re-read the history file
from the last point it was on in order to catch new histories, it should
append to the file, and it should attempt to lock the file via flock or
similar if such facilities are available (just in case).

Bash already implements this partially, lacking the update-on-recall
functionality (I believe ZSH calls its version of this "share_history"),
and lacking a way to append a history command *before* it is executed,
to my awareness.

In the event of truncation, libhistory needs to be careful not to lose
any histories that were to be submitted in between the moment of
determination of truncation and commitment of the truncation to disk.

On occasion, I wish histories were stored in a SQLite3 database :-)

As a QoL feature, bash should prevent history truncation if ran with
--norc or other flags that would inhibit HISTFILE being set potentially.
I suspect that this latter change alone would prevent the issue I was
seeing (but I can't be sure, since I never caught bash in the act of
history file truncation).

Thanks, have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]