:) "The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, [CX] or any :) other value"
:) but what you shouldn't do is expect the exit status in the shell to be :) anything other than the least-significant byte of the value you passed: :) "though only the least significant 8 bits (that is, status & 0377) shall :) be available to a waiting parent process." It is exactly what happens when compiling nerr.c with gcc: -----unsigned-8b-exit-status----- % nerr-gcc.exe; echo $? 254 sizeof (int) = 4 [B] on i686 :) So -2 comes back as 254. Sounds like perfectly correct 2's complement :) arithmetic to me! Indeed, but same arithmetic should apply when exit status comes from a "cl compiled .exe". It is not the case when compiling nerr.c with cl: -----wrong-nil(!)-exit-status----- % nerr-cl.exe; echo $? 0 $? cannot distinguish exit(0) from exit(-2) ... this is logical anarchy! One cannot reliably test exit status of legacy windoze binaries. :) cheers, :) DaveK ksh :) yields the same Cygwin bug. Thanks for answers. Daniel. -- 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/
