[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: If $HISTFILE is set to /dev/null and you execute more commands than $HISTFILESIZE, /dev/null is deleted.
Date: Sat, 31 Jan 2015 17:49:16 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]