On Thursday 06 Sep 2012 07:18:55 Brian K. White wrote:
On 9/6/2012 6:35 AM, Graham Anderson wrote:
On Thursday 06 Sep 2012 06:31:49 Brian K. White wrote:
On 9/6/2012 6:00 AM, Graham Anderson wrote:
On Thursday 06 Sep 2012 05:01:52 Brian K. White wrote:
Another example I saw a while back was rsync. rsync hasd had a certain set of exit values with various meanings, all nicely documented in their man pages and also predating systemd by over 10 years? Yet systemd called rsync's behavior a bug because there were some exit values other than 0 that didn't necessarily indicate an error.
That particular issue seemed pretty clear cut to me, posix defines 0 or EXIT_SUCCESS(0) as the *only* indication of clean termination. If software catches a signal which is meant to cleanly terminate the program and issues something other than 0, and this is against conventions and standards, why can it not be considered a bug?
Cheers the noo, Graham
No that is not what posix says.
Sorry, but it 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."
Nowhere in there does it say that any other value besides 0 necessarily indicates an error.
I actually didn't mention errors, but the same also applies. A preceeding section of text of course defines EXIT_FAILURE(1), anything else being undefined.
There are 255 exit values and only 2 of them have a standard meaning, the rest are undefined and left to the user to use as they please.
Exit values are informational, and sometimes there is more than one form of "success" when a program exits, and sometimes you have some reason to care about that and want to know it. Sometimes a whole range of different possible occurances are equally "successful" outcomes, but they are different, and you need to convey that difference, and you can't or don't want to via say stdout/stderr or writing to a file etc.
Yep of course and thanks for helping me make my point, exit(14) as defined in your application as "blueberry pie" may arbitrarily mean success, or failure, or something else to you or your app, but not to anything else because 14 is _undefined_. So the correct way to indicate successfull termination to software that has no clue what the exit status blueberry pie means is of course 0. So when a piece of software asks that another process shuts down and then asks if it did so cleanly, why would blueberry pie be a correct answer if it only knows about what is defined in posix? Which is the whole crux of that rsynch bug report. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org