On 9/6/2012 8:03 AM, Graham Anderson wrote:
On Thursday 06 Sep 2012 07:21:07 Brian K. White wrote:
You don't read very well. It says only that 0 should never indicate an error.
Why do you have to be such an obnoxious pedant, taken together the whole paragraph is:
"A value of zero (or EXIT_SUCCESS, which is required to be zero) for the argument status conventionally indicates successful termination. This corresponds to the specification for exit() in the ISO C standard. The convention is followed by utilities such as make and various shells, which interpret a zero status from a child process as success. For this reason, applications should not call exit(0) or _exit(0) when they terminate unsuccessfully; for example, in signal-catching functions."
The preceeding text that is relevent is:
"The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other value, though only the least significant 8 bits (that is, status & 0377) shall be available to a waiting parent process."
What I stated, and what I *only* stated, is clear and obvious. 0 is the only definition of success in the spec. Please show me where it states that successfull termination is defined as something else? It's also clear that failure is _only_ defined as 1. Everything other than 0 or 1 is clearly _undefined_ and arbitrary.
I'm sorry that you don't understand logic and consider it pedantry, but this is technology not art. Things are, or are not. They are not "understood". A line of code only does what it says, and nothing else. Manuals and specifications are written the way they are very carefully. It's essentially the same as "legalese". Anything that is not explicitly or even implicitly defined, is left that way deliberately and consciously, not through omission, and it does not mean that those undefined things actually mean something you happen to imagine. You do not appear to know how to read very well. It has nothing to do with pedantry. The computer is not a pedant, it's a machine that only does what is programmed. Manuals that describe the machine and the programming likewise only describe the actual behavior. What they don't say is as important as what they do say. That should be almost the first thing you learn when learning how to read manuals on anything, not just software. Calling that understanding pedantry exposes you as not really understanding science or technology. If I write a line in a manual that says "...the interpreter" you are not free to assume I meant bash. If I meant bash I would have written bash. Since I didn't specify bash, it means that any interpreter could be used. Even if bash is the only one that anyone currently uses in that particular context, it's still inaccurate to say bash, unless bash is actually the only thing that could be used. It's not pedantry is plain accuracy and communication. You want to be a fuzzy mashed potato head, be my guest but you don't actually get to call anyone else wrong for not being equally mentally sloppy. The spec DOES NOT say that 0 is the only valid exit value when the program had no error. What it says is: 0 always means true 1 always means false It does not say that 5 can't also mean "success, type 5" Let's say I have a program that processes files in a directory. I run the program and it scans a directory and does something with the files it finds there. There are _any number_ of possible eventualities in that process that could be considered an error or not depending. Let's say if the program runs, the directory exists, is readable, contains files, the files are readable, the files are of the expected format, the files are successfully read and processed, the files are successfully disposed of, and nothing unexpected happened during that entire process. At the end naturally, the program should probably exit with 0. What if the directory contains no files? Is that an error? Not in most such cases. In most situations where you're polling a drop directory then in fact 99% of the time there will be no files. It's not an error. You MAY want the program to exit 1 to indicate no-files-found, but then again you may not, because you may instead need to detect _actual_ errors, such as the program crashing or a malformed file etc. You may also not want the program to exit 0 because maybe finding files is different than not finding files. In that case you exit 2 and you put in the man page what 2 means, and any software that doesn't allow for that, is by definition, by that posix definition, wrong. What if the directory doesn't exist? Is that an error? No, not necessarily. It may be perfectly within the defined operation of the program that the directory is optional and if it's not there, then don't worry about it. Not finding the entire directory may be exactly the same as finding the directory but no files. You may want to know the difference however and so you may define that as exit 3, if you wish. And you may want to do that for the same reasons as the previous example, because you may want to reserve exit 1 for _actual_ errors. What if the directory exists and some files exist but one of the files is unreadable? Or write-locked? Or malformed? No, No, and No, at least not necessarily. Perhaps the directory may intentionally contain a mix of files but the program only cares about specific ones and intentionally simply ignores any that don't match some specification. Maybe an unreadable or write-locked file is in the process of being created and the program should simply ignore it, because some other later time the program runs that file will be done and released and _then_ the program can take it. Then again for some other program in some other situation all of those _could_ constitute an actual failing because maybe some other component is obligated to only ever run the program after depositing files etc. What if the program started running and received a USR1 signal and aborted it's operation without completing it. Is that an error? Who knows? Depends on the program and what it's doing and why. You may want it to exit 1 to indicate it "failed" to complete something it started, then again you may not necessarily consider that a problem because of _why_ it failed to finish. After all, it was politely asked by a signal, and successfully closed the input file gracefully and successfully avoided creating or leaving behind any incomplete and inconsistent output data. -- bkw -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org