Re: skip rewriting history if exiting due to signal

[Bart Schaefer <schaefer@brasslantern.com>]

On Sun, 17 Oct 2004, Wayne Davison wrote:

> Here's a patch that makes the savehistfile() function use a temporary
> file whenever it writes out the whole file from the start (rather than
> overwriting the existing file).  This could be controversial if someone
> out there has a symlink for their history file

Hm.

- It requires a writable directory rather than merely a writable histfile.
  Perhaps fall back to the old behavior if the directory is not writable?
  Similarly, perhaps detect when the histfile is a symlink and fall back?

- You haven't tested for failure of unlink() [though I'm not sure what the
  response to such failure would be ... except see below about O_EXCL].

- You haven't tested for failure of rename() -- and note that rename() may 
  falsely report failure in the event of certain NFS errors.

> The naming scheme I chose to use was to write out the history data using
> the name $HISTFILE.$$ since this naming idiom is already used for a
> temporary file name when acquiring the $HISTFILE.LOCK lock file

I wasn't aware of that latter; it should be changed.  Using the PID as a 
disambiguator is also not safe when NFS is involved (two shells with the 
same PID on different hosts may be accessing the histfile in the same 
NFS-mounted home directory at the same time, unlikely as that seems).

At the very least you should be open()ing with O_EXCL, and be prepared to 
recover if that fails (although O_EXCL is not reliable over NFS).

> If folks think that $HISTFILE.new is a better choice, it would be easy 
> to change.

No, that'd definitely be worse (even more likely to have conflict when 
multiple shells are rewriting the history), not better.