Re: Failing to write to history file if containing directory doesn't exist

[Matthew Wozniski <godlygeek@xxxxxxxxx>]

On Mon, Oct 08, 2007 at 05:30:08PM +0200, Nikolai Weibull wrote:
> On 10/8/07, Matthew Wozniski wrote:
> 
> > I don't know that I'd be shocked, but I would err on the side of
> > a smaller, faster, more maintainable shell, given how easy to handle
> > in shell code the problem is.  Shell code is more easily maintained
> > than C, and for an error condition that should only exist when the
> > HISTFILE parameter is set, I think adding code to the shell itself
> > would be overkill.  If you're already setting HISTFILE yourself, it's
> > not too much extra work to add an mkdir -p above it.
> 
> And what if the directory gets deleted between the time HISTFILE is
> set and the shell exits?
The only way that should ever happen is if the user removed (or moved)
the directory himself.  If that's the case, the shell should certainly
not recreate a directory that the user intentionally deleted, each and
every time the history is updated.  That would make it impossible for
a user with HISTFILE=~/.zsh/history to do something as simple as:

% mv .zsh .zsh-4.3.4
% ln -s .zsh-4.3.4 .zsh

without first unsetting and later setting HISTFILE, since the
directory would be recreated between the two commands.

> I'd rather err on the side of a more intelligent, "work hard for the
> user"-type shell that doesn't let my data disappear out into oblivion
> without doing its best to keep said data around.

But really, you're talking about recreating a directory that was just
deleted.  In this case we really ought to err on the principle of
least surprise.  After all, that directory didn't just get up and walk
away, someone had to delete it.  ;)

~Matt