<<< Date Index >>>     <<< Thread Index >>>

Re: Mutt 1.5.16 editor exit status brain damage



On 2007-06-16 13:18:57 -0400, Derek Martin wrote:
> On Sat, Jun 16, 2007 at 06:50:22PM +0200, Vincent Lefevre wrote:
> > > No, that's not correct.  Strictly speaking, the shell assumes an exit
> > > status of 0 evaluates to TRUE, and any non-zero exit status evaluates
> > > to FALSE.  Any interpretation about whether that means success or
> > > failure is open to interpretation by the author.  Over time, shell
> > > programmers, and in some cases shell man page writers have assumed
> > > what you are assuming: that the meaning is success or failure.  But
> > > that is false.
> > 
> > The shell treats nonzero values as if they were errors (e.g. "set -e"
> > makes the shell script exit in such a case). 
> 
> Sorry, that's not correct.  The shell with set -e treats nonzero
> values as errors.  Otherwise the shell makes no such assumption
> inherently.

They don't magically become successul values just because "set -e" is
not used. Another example: if the command is the last one this is also
the value returned by the shell. Without additional knowledge, such
values need to be treated as errors (e.g. one can't make the difference
with redirection failures).

> > > Case in point: fsck returns an exit status of 1 when it repaired
> > > filesystem errors.  This is not an error condition of the program, it
> > > is actually a success.
> > 
> > Not necessarily a success: there were filesystem errors, and though
> > they were corrected, files may have been lost or may be corrupt.
> > This must be reported to the user, hence the nonzero exit status.
> 
> No, necessarily a success, i.e. from the perspective of fsck, the
> program ran successfully without error.

The "successfully" is just a point of view, just like "diff", which
returns 1 if there are differences, which can be seen as an error by
the user or not, depending on the context. But how can "diff" know?
If the user doesn't like differences being regarded as an error, he
can wrap "diff", etc.

> So?  The old way is still obviously better.  The old behavior rarely
> affected anyone,

But when someone is affected, this can be critical (e.g. privacy data
sent by mail if the user thought he had removed these data, but the
editor failed...).

> whereas the new behavior affects ALL users who use vi on two (or
> more) operating systems. That's pretty obviously worse.

Not much users, and these users should know how to write a wrapper.

> > The fact that the file has changed doesn't mean that the user could
> > edit it successfully. For instance, the user may save the file a
> > first time (so, the file has changed), continue to edit it, then
> > save-and-close, but at this time, the editor may crash or fail (e.g.
> > exit with a nonzero status).
> 
> Indeed.  There's no truly "right" solution.  See my last message for
> treatment of this.

Having a wrapper for a few users is better than adding bloat to Mutt
for every user.

Also, I've noticed that you didn't answer this from my mail: vi
reports interesting numerical information back to Mutt and Mutt
reports it to the user. What's wrong with that?

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)