This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: More error level issues
Brian Bruns wrote:
> Yeah, I know of that post. I'm still _highly_ confused as to this -
> chalk it up to the fact I'm more used to dealing with return codes in
> Linux, so forgive my ignorance. I'm also not the greatest programmer
> in the world.
>
> Your telling me an exit code of 1 inside of cygwin (and Linux for that
> matter) is supposed to be considered as errorlevel 256 by Windows
> rather then 1? I'm sorry if I am not catching on here entirely of why
> this is.
Under unix, the "process completion status" is an integer, and is the
value returned by the wait() family of functions.
Bits 0(LSB) through 7 of this integer convey information about how the
process was stopped. Bits 8 though 15 contains the exit value that the
program supplied to exit() or to its main() function.
If the value of bits 0 through 6 is zero then it means the program
terminated normally, and the exit status is in bits 8-15.
If bits 0 through 6 are all set then the process was stopped, and the
value of the signal that caused the stop is in the exit value field.
If bits 0 through 6 are not all zeros or not all ones then the process
was terminated by a signal, and the value of the signal is the value in
those bits.
Bit 7 signifies whether a core dump was produced.
Anyway, what cgf is saying is that under linux if you call wait() on a
process that "returns 1", i.e. calls exit(1), the process completion
status will be 256. Your shell handles interpretating the completion
status so that it knows how the process ended, and sets $? to the
"return value".
(The SUSv3 defines all this in terms of macros in sys/wait.h to check
the process completion status, so the actual bits are probably not an
actual standard but certainly a de-facto one.)
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/