On Friday, June 15 at 05:51 PM, quoth Derek Martin:
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.
I didn't mean "standards" as in "you're mixing the X standard with the Y standard", I meant it in terms of "you're holding general applications to one standard (i.e. they can do whatever they like) and mutt to a different standard (i.e. it is forbidden from doing whatever it likes)."
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.
Of course, and I would agree, however, the definition of what is a "standard utility" is a bit vague, wouldn't you say? I mean, what makes something a standard utility? The fact that 'vi' and 'fsck' are distributed with virtually every version of UNIX certainly makes them a de-facto standard. They are also useful programs, which makes them "utilities" as well. Aren't they both therefore "standard utilities"? Or maybe "standard" in POSIX means something else?
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?
<sigh> Why on earth would other arguments I may have made about unrelated (unnamed) details have any bearing on this discussion?
Not that it matters, but I agree that mutt shouldn't prevent people from doing unwise things. I suggested mutt be made more flexible rather than that mutt be made to prevent anyone from doing anything unwise, thus being consistent with my (apparent) reputation. But again, why should my reputation matter?
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.
I like how you conveniently positioned yourself such that, should anyone choose to find shell documentation contradicting you, you'd simply claim that the documentation is wrong (no matter whether every man page of every shell said it or not). But fair enough, you're right. "True" can, strictly speaking, mean anything.
Your statement is not correct, and Mutt does not have the right to make such an assumption.
Of course it does. Is making this assumption illegal in any country on earth? Will anyone be jailed, fined, or killed if mutt makes this assumption? No, of course not. Even if the assumption is *WRONG*, mutt has the *right* to make any assumption it likes. In fact, mutt has the *right* to have bugs in it too, which may have the effect of (or have as their cause) making all sorts of assumptions.
If you wish to argue that mutt does not have the right to assume whatever it likes, then I would ask: by what authority?
Of course, that then gets into a more philosophical argument about where "rights" come from, but the same logic can then be applied to the so-called "right" of programmers to use whatever return value they wish. From whence does this "right" come?
Rules of logic dictate that if a premise is not always true, then it is false.
You wanna get nitpicky, lets get nitpicky. Otherwise, let's stop treating me like an idiot and attempting to explain "rules of logic" to me.
Since turnabout is fair play... Premises may have truth that is dependent upon context. For example, every day around noon I go in search of sustenance. My actions are based upon the premise that I am hungry. Once I have eaten, I am no longer hungry. This does not mean that I was never hungry and never will be hungry, despite the fact that the premise "I am hungry" is not always true. A premise is, after all, only a claim (either true or false). Only universal claims, such as "I am always hungry", are false if they are not always true.
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.
Not necessarily. It really means one of two things: either the old behavior was right, or it was wrong in a way that didn't cause people to complain for 9 years.
I mean, just because we can find buffer overflows in sendmail (assuming that we can) that are nine years old or more doesn't mean that those buffer overflows are actually correct behavior, even if the initial fix breaks sendmail on some major operating systems.
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.
That sounds reasonable.Mutt should probably also check for things like SIGSEGV and such as well, though.
~Kyle --And thou shalt smite the house of Ahab thy master, that I may avenge the blood of my servants the prophets, and the blood of all the servants of the LORD, at the hand of Jezebel. For the whole house of Ahab shall perish.
-- Bible, II Kings (9:7-8)
Attachment:
pgpSn9FcI0Uby.pgp
Description: PGP signature