Zitat von Olivier Andrieu <oandrieu@nerim.net>:

> On Jan 21, 2008 1:27 AM, Oliver Bandel <oliver@first.in-berlin.de>
> wrote:
> > Hello,
> >
> >
> > I stumbled over a problem that I until now have not seen as a
> problem...
>
> > So some questions arise:
> >     *  negative signal-numbers - how can that be?
>
> $ ocaml
>         Objective Caml version 3.10.0
>
> # Sys.sigpipe ;;
> - : int = -8
[...]

Oh, an unusual way ;-)



>
> The caml runtime library just uses negative signal numbers.
>
> >     * why does that code not work?
>
> It does work. It's just that since you close the channel before the
> zcat process has finished writing all of the decompressed data, it
> dies because it gets a SIGPIPE signal.
[...]


Oaaaaahhhr, yes.
Thanks for the hint.

Normally I read the data complete.
This time I did not (because I only want 1KB
for my Digest). That was, what I have overseen.


>
> >       In a different tool I have included that compressed module
> >       and it works well, tested even with the same gz-file.
> >       Is there a bug in "id_of_file"?
> >
> >     * How can it be, that close_process_in as well as close_in
> >       are working on variables of the same type?
> >       Isn't this a hole in the typesystem?
> >       Or can normally both functions, Unix.close_process_in as well
> >       as Pervasives.close_in be used on that channels?
> >       And: why is it not working here?
>
> Unix.close_process_in calls Pervasives.close_in, ultimately. Before
> that, it uses the channel to lookup in a hashtable the pid of the
> child process, so as to wait() and report the status of the child
> process.
[...]

Because the type that both functions accept are the same,
there should be no problem to use one for the other...
... what's the exit value of a process, that is no process? ;-)
So, channels have some hidden values that take care of
process issues...?!

Ciao,
   Oliver