On 16-Nov-1999, Malcolm Wallace <[EMAIL PROTECTED]> wrote:
> The Haskell Library Report informally defines the function System.system
> as follows:
> 
>   Computation /system cmd/ returns the exit code produced when the
>   operating system processes the command /cmd/.
> 
> This is fairly vague. [...]
> if you try the same test in C, using the
> system(3) call:  the man page says:
> 
> >                       system() then returns the exit status returned
> >    by wait(2V).  Unless the shell was interrupted by a  signal,  its
> >    termination status [i.e. the shell command] is contained in the 8
> >    bits higher up from the low-order 8 bits of the value returned by
> >    wait()

That is POSIX specific.  The C standard merely says that system()
"returns an implementation-defined value".  I don't know off-hand
what typical non-POSIX systems do.

> Currently, nhc98 matches C's behaviour by giving the result code
> returned by the operating system (i.e. 256/512/etc).  Currently, Hugs
> and ghc give the (more natural) shell result code, not the one returned
> by the operating system.

We ran into this same issue during the development of Mercury,
and we chose to have Mercury's `call_system' procedure return the
shell result code, treating the cases where the invoked command
was interrupted by a signal as errors.

I think that this approach would be best in Haskell too.

The only other portable alternative that I can see is to use the
C approach of saying that the result is implementation-defined.
But it should be possible for a Haskell program to invoke another
Haskell program that was compiled to a separate executable
and to examine the return status without having to write
system-dependent code.  If the result of `system' was
implementation-defined, that would not be possible.

But I do see one problem with this approach given the current specification.
Looking at the Haskell 98 Library Reference, I see that it says

 | Any System operation could raise an isIllegalOperationError, as
 | described in Section 11.1; all other permissible errors are described
 | below.

and then the description of `system'

 | Computation system cmd returns the exit code produced when the operating
 | system processes the command cmd.

does not specify any other permissible errors.
That indicates that the only error that it can raise is
`isIllegalOperationError', which does not seem like an
appropriate error in the case where the command was invoked
but was interrupted by a signal.  Nor does it seem like
an appropriate error if the command could not be executed
due to lack of memory.  (That second complaint also applies
to many other operations in the `System' and `IO' modules.)
The current set of restrictions on errors does not seem very
satisfactory, IMHO.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]        |     -- the last words of T. S. Garp.

Reply via email to