Re: [OT] Not clobbering bash history

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

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

Hi,

Richard Stallman <rms@gnu.org> writes:

> [[[ 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.

I mean the action usually bound to C-p (I believe the libhistory
function is previous_history).

>                                           try to re-read the history file
>   > from the last point it was on
>
> What does "last point it was on" mean?

Say that the history has eight entries, and a ninth was added by a
parallel process, the current process would be at the point after the
eighth element and should continue reading from there next time it wants
a history entry.

>                                   in order to catch new histories, it should
>   > append to the file,
>
> What should it append, and in what circumstances?

New history entries, always (i.e. it should only ever append, as if via
O_APPEND, to ~/.bash_history and friends, at least while not holding
locks).

>                         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.

Not necessarily.  If both shells use a single write() syscall on an
O_APPEND file, they should work as expected to my awareness.  But, if
not, then locks would help (flock-ing the file before adding an entry
ensures only one shell is ever writing to enable correct history
storage).

>   > In the event of truncation, 
>
> What truncates the file?  When does that occur?

bash/libhistory would need to if it'd like to rotate the history file
due to HISTSIZE.

> Is such truncation _supposed_ to occur, or is it a bug that it occurs?

Depends.  If the user sets HISTSIZE to, say, 500, and enters a new
command, and it'd have been the 501st, the history file would need to be
truncated to be rotated.  In that scenario, it is intended.  If the user
did not intend to have HISTSIZE set to a positive value, then any
truncation is a bug (as history would be lost).

>                                 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.

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.

Hence, libhistory needs to be careful to prevent this.

>   > 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?

I meant to say HISTSIZE here.  My apologies.

If HISTSIZE is set in my RC file to a negative value (per (bash) Bash
Variables, this should inhibit history file rotation and/or truncation),
but if a shell is started with --norc (by, say, TRAMP, perhaps), then
bash would not be aware of the users desired HISTSIZE.  In that event,
it should be conservative and *not* overwrite the users' history.

I suspect that the latter is what was causing sporadic truncation in my
case (but I haven't confirmed so unfortunately).

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

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