Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.

[Chet Ramey]

On 1/30/15 4:39 PM, Jonathan Hankins wrote:

> And with both rename()
> calls, ERRNO should be reported to the user if they fail.

No.  The return code should indicate whether or not the history file
was written correctly.  Failing to backup the history file should not
affect that return value, since it doesn't affect whether or not the
history file is overwritten.  If a write error occurs that causes the
history library to attempt to restore the original history file, that
write error is what should be returned to the caller.

> As far as open() on HISTFILE for append or truncate, when user is root (or
> when user has owner or group write to the file), I think bash (readline?)
> shouldn't overwrite, append to or rename non-regular files.

You're basically advocating that root should not be able to use a non-
regular history file.  Other than the backup issue I mentioned in the
previous message, I don't think there's any reason to be that restrictive.


> I also think the handling of the case where HISTFILE is a symlink may
> misbehave (it would read the history in from the file the link refers to,
> but on overwrite, replace the symlink, instead of the file it refers to.)

I'll look at this.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/