[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OT] Not clobbering bash history
From: |
Richard Stallman |
Subject: |
Re: [OT] Not clobbering bash history |
Date: |
Sun, 03 Dec 2023 22:10:44 -0500 |
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I am trying to understand the words you wrote.
> libhistory should, on recall attempt,
What does "recall attempt" mean? I don't know that term.
try to re-read the history file
> from the last point it was on
What does "last point it was on" mean?
in order to catch new histories, it should
> append to the file,
What should it append, and in what circumstances?
and it should attempt to lock the file via flock or
> similar if such facilities are available (just in case).
If two different shells will try to write history into one single file,
are they doomed to give bad results, one way or another> It seems to me
that the crucial thing is for them to use two different files.
> In the event of truncation,
What truncates the file? When does that occur?
Is such truncation _supposed_ to occur, or is it a bug that it occurs?
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.
I don't follow.
> As a QoL feature, bash should prevent history truncation if ran with
> --norc or other flags that would inhibit HISTFILE being set potentially.
I don't understand this point -- can you explain?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)