Eric Blake wrote: > Linda Walsh wrote: > >I guess I don't use negative return codes that often in shell, but > >I use them as exit codes reasonably often.
For all of the reasons Eric mentioned you won't ever actually be able to see a negative result of an exit code however. > >'return' barfs on "return -1"... > > > >Since return is defined to take no options, and ONLY an integer, > >as the return code, it shouldn't be hard to fix. > > According to POSIX, it's not broken in the first place. Portable > shell is requires to pass an unsigned decimal integer, no greater > than 255, for defined behavior. > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#return The reason for that is for compatibility. Originally the exit status was returned in a 16 bit integer with the lower 8 bit byte holding the exit code and the upper 8 bit byte holding the status. The <wait.h> macros WTERMSIG et al were used to extract that information. (I don't know if all of that is still true but that is the way it used to be.) And so in the C programming man page for exit(3) it says: man 3 exit The exit() function causes normal process termination and the value of status & 0377 is returned to the parent (see wait(2)). Note the "status & 0377" part. That is an octal 0377 or 255 decimal or 0xFF hexadecimal or just the lower 8 bits. Trying to return a value that won't fit into 8 bits just isn't possible. The traditional man pages always described the size as an 8 bit value and specified the range as 0 through 255 implying that it was an unsigned value. Historical documentation for exit(3) http://www.freebsd.org/cgi/man.cgi?query=exit&apropos=0&sektion=3&manpath=2.9.1+BSD&format=html Now you might argue that -1 is always going to be all ones in two's complement. Sure. But traditionally it has always been unsigned. Bob