I appreciate your insight, but please, please do not cripple (system) any further by making the return value a boolean--it reduces its utility immensely. 'process' is not always a good substitute [and has the same signal/exit code conflation issue]. And 'osprocess' is just far too heavy for what should be a simple call to system().
I can live with (system) returning either an exit code or a signal; the value may be overloaded but it is still a good debugging aid. Though I still feel a true system should just return the raw value, if I did need the raw value I would just pull out and modify the code from Chicken. To answer Mario's question, the result returned from system() is either the exit status or the signal number on any modern UNIX machine; this is the same as described in process-wait. It also returns 127 upon shell execution failure (I tested this) and 'errno' upon waitpid or fork failure [again, cannot distinguish this from signal or non-zero exit code]. This is well-defined and useful information, so I think that the current return value behavior for UNIX should at least be documented. On 3/14/07, Kon Lovett <[EMAIL PROTECTED]> wrote:
For the library unit 'system' return value: 1) Store the return & exit status for the last call & provide accessors, as you suggested. Return the C 'system' call return value. 2) Multi-valued result, a'la 'process-wait'. 3) Return boolean value. I kinda prefer #3. If the user needs more, use a more complicated interface. The posix unit 'process' & 'process*' already have a shell- command mode.
_______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users