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. > > 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 state of the filesystem has nothing to do with whether or not fsck ran without error. There may well be data loss, but that's out of fsck's sphere of control, and up to the system administrator to determine, not fsck. When fsck returns 1 to the OS, it has in fact run successfully, i.e. it did everything it was programmed to do correctly without error. > > 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. > > The GNU cmp utility has been buggy for at least 15 years. And during > this time, no-one reported the problem. Still, this was really a bug, > which has eventually been fixed. So? The old way is still obviously better. The old behavior rarely affected anyone, whereas the new behavior affects ALL users who use vi on two (or more) operating systems. That's pretty obviously worse. > 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. -- 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:
pgpURGJQjf5S9.pgp
Description: PGP signature