question about saving history and error reporting

question about saving history and error reporting

[frederik]

Hi Zsh Workers,

My disk filled up recently and I noticed that although Zsh was not
able to write to the history file, it did not print any error
messages. I see lines like this in the source code:

hist.c:2921

        zerr("failed to write history file %s: %e", fn, errno);
        
Do I have to do something special to have these errors printed to my
terminal? I notice that it prints the messages if I do "chmod u-w
~/.zsh_history" and start a subshell and log out, but since I have
inc_append_history set, I think I should see the errors more often...

Thanks,

Frederick

Re: question about saving history and error reporting

[Bart Schaefer]

On Dec 21, 12:38pm, frederik@ofb.net wrote:
}
} My disk filled up recently and I noticed that although Zsh was not
} able to write to the history file, it did not print any error
} messages.

Incremental appends do not generate error messages (cf. hist.c:1105
where the second argument to savehistfile() is zero).

This is because (a) it would mean up to two error messages per command
executed, which could make normal use of the shell difficult/annoying,
and (b) it's assumed there will be another attempt later, either on the
next command or at shell exit, so there's no reason to report transient
error conditions.

Most likely you are not seeing the error that is generated at shell exit
because your terminal window has already closed.

It's possible that we could examine errno and decide to issue the error
anyway in potentially critical situations.

Re: question about saving history and error reporting

[frederik]

On Mon, Dec 21, 2015 at 12:54:50PM -0800, Bart Schaefer wrote:
> On Dec 21, 12:38pm, frederik@ofb.net wrote:
> }
> } My disk filled up recently and I noticed that although Zsh was not
> } able to write to the history file, it did not print any error
> } messages.
> 
> Incremental appends do not generate error messages (cf. hist.c:1105
> where the second argument to savehistfile() is zero).
> 
> This is because (a) it would mean up to two error messages per command
> executed, which could make normal use of the shell difficult/annoying,
> and (b) it's assumed there will be another attempt later, either on the
> next command or at shell exit, so there's no reason to report transient
> error conditions.
> 
> Most likely you are not seeing the error that is generated at shell exit
> because your terminal window has already closed.
> 
> It's possible that we could examine errno and decide to issue the error
> anyway in potentially critical situations.
> 

Thank you for the reply. But don't most people use terminal windows,
or screen, or some other tool which hides whatever output zsh produces
on exit?

For me, if the history can't be written, it would be convenient to
know about the errors that are being generated immediately, so that I
can fix the problem. Are there many situations where the history can't
be written due to a problem which is transient? Are there other cases
where Zsh hides errors that occur during its operation?

Well, perhaps I can just patch hist.c locally...

Thanks,

Frederick

Re: question about saving history and error reporting

[Bart Schaefer]

On Dec 22, 10:14am, frederik@ofb.net wrote:
}
} For me, if the history can't be written, it would be convenient to
} know about the errors that are being generated immediately, so that I
} can fix the problem. Are there many situations where the history can't
} be written due to a problem which is transient?

The most common reason in the case of inc_append_history could be that
multiple shells are updating the file at the same time.  There are also
things like home directories on remote filesystems that are temporarily
unreachable.

Really it's not the responsibility of the shell history mechanism to
alert you about system-wide failure conditions like a full disk, and
I wouldn't want to encourage anyone to rely on it for that.

} Are there other cases where Zsh hides errors that occur during its
} operation?

That's a rather wide-open question.  The (programmed in shell code)
completion system deliberately suppresses all sorts of errors that
might occur during generating the possible matching words, because
they're irrelevant to updating the command line and displaying them
would mess up screen for ZLE.  Within the C code, I would not be
surprised if there are other implicit actions for which displaying
an error state is considered unnecessarily verbose, but I can't tell
you of any offhand.

Re: question about saving history and error reporting

[frederik]

Thanks for the perspective.

On Tue, Dec 22, 2015 at 04:54:33PM -0800, Bart Schaefer wrote:
> On Dec 22, 10:14am, frederik@ofb.net wrote:
> }
> } For me, if the history can't be written, it would be convenient to
> } know about the errors that are being generated immediately, so that I
> } can fix the problem. Are there many situations where the history can't
> } be written due to a problem which is transient?
> 
> The most common reason in the case of inc_append_history could be that
> multiple shells are updating the file at the same time.  There are also
> things like home directories on remote filesystems that are temporarily
> unreachable.
> 
> Really it's not the responsibility of the shell history mechanism to
> alert you about system-wide failure conditions like a full disk, and
> I wouldn't want to encourage anyone to rely on it for that.
> 
> } Are there other cases where Zsh hides errors that occur during its
> } operation?
> 
> That's a rather wide-open question.  The (programmed in shell code)
> completion system deliberately suppresses all sorts of errors that
> might occur during generating the possible matching words, because
> they're irrelevant to updating the command line and displaying them
> would mess up screen for ZLE.  Within the C code, I would not be
> surprised if there are other implicit actions for which displaying
> an error state is considered unnecessarily verbose, but I can't tell
> you of any offhand.
>