close_in or close_process_in ?!

[Oliver Bandel <oliver@first.in-berlin.de>]

Hello,


I stumbled over a problem that I until now have not seen as a problem...


When I use Unix.open_process_in I get as a result the
channel of type in_channel, which means Pervasives.in_channel.

When I open a file with open_in, I get the same type.

Normally a channel of type in_channel, opened with
open_in will be closed with close_in.

An in-channel which was opened with Unix.open_process_in
can (must?) be closed with Unix.close_process_in.


In some code I have used it as described above but always got
a WSIGNALED (-8), when closing a channel that was opened with
Unix.open_process_in. This seems strange to me.


Here is the code, added with some Printf-statements and
exit-statements, which I added to have some output here.

=======================================================================0
module Compressed =
 struct

    let open_gzip_read file     = Unix.open_process_in ("zcat " ^ file)
    let close_gzip_read channel =
           match (Unix.close_process_in channel)
           with   Unix.WEXITED ret -> (* Printf.printf "Status: %d\n"
ret; *)
                     if ret != 0 then Printf.fprintf Pervasives.stderr
"errcode: %d\n" ret
                                 else Printf.fprintf Pervasives.stderr
"OK!"
                | Unix.WSIGNALED sign -> Printf.fprintf
Pervasives.stderr "Signalled.signalled: %d\n" sign ; exit 999
                | Unix.WSTOPPED sign  -> Printf.fprintf
Pervasives.stderr "STOPPED-signalled: %d\n" sign ; exit 111

  end
=======================================================================0
    let id_of_file fname =
      let (opener, closer) =
        if Filename.check_suffix fname ".gz"
        then (Compressed.open_gzip_read, Compressed.close_gzip_read)
        else (open_in, close_in)
      in

      let chan = opener fname in
        let id = try Digest.to_hex( Digest.channel chan 1024 ) with _ ->
"Bad!"
        in
        Printf.printf "RESULT: (%s) => %s\n" fname id;
          closer chan; id
=======================================================================0
Used on a file that can be displayed with zcat by hand:
----------------------------------------------------------
RESULT: (access.log.gz) => 4cf1f6420407714dea9f9d26edee428a
Signalled.signalled: -8

So, zcat can display it, this code fails when closing the file...


When I then change

 "closer chan; id" to
 "close_in chan; id"

I will get:
----------------------------------------------------------

RESULT: (access.log.gz) => 4cf1f6420407714dea9f9d26edee428a
4cf1f6420407714dea9f9d26edee428a


So, this means I get the error message with Signalled -8
when I close with the function that normally should be used.
But the resulting string shows, that the code has worked so far...
...but fails at "closer chan".



So some questions arise:
    *  negative signal-numbers - how can that be?

    * why does that code not work?
      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?


Any ideas here? Do I have a hidden (hidden for my eyes)
bug in my some lines of code, or where is the problem located?!


Ciao,
   Oliver