On Sat, Jun 16, 2007 at 11:34:27PM +0200, Vincent Lefevre wrote: > > > 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. That's right, they simply become values -- there is no inherent meaning of success or failure in them. The shell does, however, treat them as either true or false. > Another example: if the command is the last one this is also > the value returned by the shell. Up to here, correct again. > Without additional knowledge, such values need to be treated as > errors (e.g. one can't make the difference with redirection > failures). And... you got lost again. A programmer who programs without knowledge of the exit codes of the commands he is using, and instead assumes that 0 unconditionally means success and non-zero unconditionally means an error occured, will (eventually) write broken programs. There have been several examples in this thread of programs which do not conform to that convention. You are arguing from the point of view that the above convention is universally true, but it simply is not. Please grasp this idea: THERE IS NO INHERENT MEANING TO ANY EXIT CODE, IN THE GENERAL CASE. THERE IS ONLY A CONVENTION ON HOW TO INTERPRET THEM. Many programs conform to this convention, and some do not. If you can not accept that, then we are wasting our time. The convention makes sense for tools which are intended to be used as general purpose command-line utilities in shell scripts, and not (necessarily) otherwise. In other cases, the exit code can and should reflect the purpose of the program, and must be interpreted as accordingly, and not blindly as success or failure. But all of this is completely irrelevant to the point at hand. The fact is that vi on the systems in question is POSIX-compliant. So, you loose. Your argument is null and void, a red herring. > > > > 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. See above. If the user doesn't like differences being regarded as an error, he can just decide for himself that they are not. He must, however, account for the actual meaning of the exit code from diff, if he is relying on it in his programs. He can not simply assume that non-zero means an error occured. > > 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...). Yeah, I just can't take that seriously. I've been using Mutt for mail most of the time it's existed, and I've never had vi fail in a way that I could not detect. > > 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. HUH? All users of Mutt who use vi on these two operating systems is "not much users"? That's absurd. And your assertion that those same users should be capable of writing wrapper scripts is likewise absurd. It assumes that anyone who can use Mutt and vi are programmers, or want to be. That's ridiculous. > > > 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. If it were actually bloat, I might agree. But code which is necessary to make Mutt work in your operating system without falsely reporting errors can hardly be labeled "bloat" I would say. And, again (for like the third or 4th time now) end users should never be required to be programmers of any sort, even lowly wrapper script programmers, in order to make their end-user applications behave sanely, intelligently, and/or reasonably. As soon as an end user needs to write a single line of code to make your application work correctly, you have a flaw in your program that needs to be fixed. For purposes of interpreting the previous paragraph, by "end-user applications" I am refering to programs intended to be used by non-programmer computer users for work not related to programming or the maintenance of a computer system. Like, for example, reading and sending mail. > 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? What's wrong with it is that it is a false statement, like almost all of your arguments have been. In point of fact, vi reports information that may or may not be interesting, and in the case of vi on Solaris 10 and SCO, mostly isn't, resulting in Mutt falsely reporting that an error has occured, after very likely nearly every message. That's what's wrong with it. I didn't answer your question because I have already answered it repeatedly, and frankly because the answer is bloody obvious. -- 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:
pgp38fz57zjcD.pgp
Description: PGP signature