On Sat, Jun 16, 2007 at 02:34:46PM +0200, Vincent Lefevre wrote:
> > Mutt CAN NOT make assumptions about what the exit status means.
>
> The only way to avoid making assumptions is to follow what the
> standards say (regarding all exit status values as equivalent is also
> an assumption). And POSIX is clear: 0 = success, nonzero = failure.
I don't have a copy of the standards handy, since IEEE charges to
obtain them, but I believe what the standard says is that 0 = success,
nonzero = error. Error is not necessarily failure. Therein lies the
essential problem. The C standard defines EXIT_SUCCESS and
EXIT_FAILURE; however the C standard does not dictate the behavior of
the programmer or his applications -- it merely defines what features
must be available in an implementation to be compliant with the C
standard. We must not confuse the two.
It is also worth noting that Mutt doesn't necessarily run only on
POSIX systems. Still many older Unix systems which do not conform to
POSIX standards exist, and AFAIK still run Mutt. A design goal of
Mutt always was maximum portability.
In any event, your argument is false, since the reason this problem
exists is that vi on Solaris 10 and SCO *ARE FOLLOWING THE POSIX
STANDARDS EXACTLY*, and Mutt is not currently dealing with the result
in a reasonable way. Realistically, this is not Mutt's fault, but
Mutt must deal with the world in which it lives. Please allow me to
emphasize: Mutt does not work correctly with THE standard Unix editor
on two major, POSIX-compliant operating systems (possibly more).
Clearly, Mutt is wrong (i.e. needs to make an adjustment).
The dilema is that following the standards requires that you either
report an error (in Mutt) where no meaningful error has occured, or
ignore errors from the editor completely. Reporting errors when no
meaningful error has occured is horribly gross. If my mailer did
this, I would very quickly switch to a different one. Fortunately, we
can detect whether the message has changed, and generally ignore
errors, but this is not a perfect solution either. It will be
possible that an editor will change the file, but still have an error
that might be meaningful. The likelihood of this is extremely low,
however. Normally vi (and emacs, and every other sane editor I can
think of) reports all such errors before it actually exits. For
people using less robust editors or custom code though, it could cause
an issue. But I'd rather this than live with an error being reported
after every message I type.
Probably the standard is dumb... An interactive program should
probably only return an error exit status when there has been a fatal
error preventing the user interface from loading, or from exiting
properly. But unfortunately, that's not what the standard specifies.
This is a fine example of why I always say blind adherence to
standards is dumb. It's also a fine example of how monolithic
programs can sometimes work better than "The Unix Philosophy." A
mailer incorporating its own editor will never suffer from this
dilema.
I think Mutt either needs to revert the change, or (probably better)
we need a new function to deal with spawning the editor that does not
check the exit status at all, but instead checks whether the message
changed. Note this only applies to the editor, not to other system
commands.
This applies to the editor, and only to the editor, because:
- it is (generally) an interactive program, and the user should be
able to detect when a meaningful error has occured
- It can not be determined reliably from the exit status of an
interactive program whether a meaningful (to the calling process)
error has occured
- Editors which follow the standards produce results which confuse
Mutt.
- The desired result (an edited message) can reliably be determined
to have been effected or not by checking the timestamps on the
file. In the case of the editor, mutt should prompt on whether
the message has changed, not whether an error has occured.
Presumably, the user should already know that an error has
occured, since the editor will have told him.
- Even in the case of a non-interactive program being used as an
editor (which will normally be a one-off, since for nomral mail
manipulation this is not terribly useful), it can still be
determined if the message was changed without checking the exit
status.
It does not apply to other system commands, because:
- The standards assume that "standard utilities" have a non-zero
exit status when an error condition has occured
- In cases not involving the editor, it can not reliably be
determined that the forked program behaved according to
expectations, other than by checking the exit status.
- If users use programs for other tasks, such as display filters,
MIME handlers, etc., and they are using programs which do not
conform to the properties of "standard utilities", it is
reasonable to assume that the user is a "power user", and that the
program they are using is custom code, and therefore the onus is
on the user to make sure the exit status conforms to what mutt
expects. [This should be documented clearly, however.]
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
Attachment:
pgptExVRPMyGd.pgp
Description: PGP signature