On Fri, Jun 15, 2007 at 02:06:10PM -0600, Kyle Wheeler wrote: > Now wait a minute, you're mixing standards here. No I'm not. The OP's version is technically compliant to the standard. It is exiting with a non-zero status when an error has occured. I should be able to stop here, as that is proof that the current behavior is wrong. But I'll continue. IIRC, the POSIX standard mandates the exit status of "standard utilities" -- an author of a program which is not a "standard utility" can use the exit status in whatever way is convenient. It could be used to pass interesting numerical information back to the OS (calling process). There's no reason an author should avoid this behavior if it makes sense for his application. > You have the *right* to jab yourself in the eye with a fork, but > it's probably unwise. Aren't you one of the people that argues that Mutt should not prevent people from doing things that are unwise? > For example, most shells (including /bin/sh, even when it's not an > alias for bash) make the *assumption* that an exit status of 0 means > success and that anything else means an error of some sort. 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. > It seems to me that making the same assumption that every single major > shell makes (i.e. that a non-zero status code means that an error > occurred) is perfectly reasonable (and mutt of course has every > *right* to make that assumption). Your statement is not correct, and Mutt does not have the right to make such an assumption. Such an assumption is false, even if it is true *BY CONVENTION* in the majority of cases, and by standard in some cases. Rules of logic dictate that if a premise is not always true, then it is false. 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. There are errors on the filesystem, sure; but that is not a failure case for fsck. Rather, fsck has succeeded fantastically at doing what it is supposed to do. But it still returns a "failure" exit code. But this is for very good reason, and consumers of fsck's exit status need to be aware of this. > So which route should mutt take once it has made the assumption (that > it has every right to make) about what the exit code of the editor > means? Doing nothing is undesirable for some, and doing something is > undesirable for others. It has been doing nothing (based on the exit code) for 9 years, and AFAIK only 1 person has complained. By contrast, the current behavior is broken for users of vi on 2 major operating systems (at least, possibly more). Which behavior is correct? The answer is obvious: the old behavior is correct. > It may be worthwhile to add a configure option to mutt that allows > the user to specify whether their editor's exit status matches the > de-facto standard shell semantics (and thus non-zero codes should be > considered actionable errors) or whether their editor's exit status > should be ignored. That doesn't seem worthwhile to me. Mutt can detect if the user was able to edit the file by seeing if it changed after the editor ran on it. If it didn't change, mutt should (at least provide an option to) prompt the user about what to do. It can not and should not make assumptions about the meaning of the exit status of the editor. -- 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:
pgp6sOcrmuNwx.pgp
Description: PGP signature