Comment author: @dbuenzli

I would actually expect exactly what happened to you. The documentation is quite clear, Unix.close_process_in closes the channel. See the documentation of Pervasives.close_in to see what that means.

Comment author: @mshinwell

Unfortunately I think there may be a bug here. I think the fact that the example involves [Unix.process] functions isn't relevant.

Looking at the documentation for [close_in], I see:

"Input functions raise a Sys_error exception when they are applied to a closed input channel"

which makes me think that [input_line] should raise [Sys_error], not [End_of_file]. However, the implementation of [input_line] (in particular, the function [caml_ml_input_scan_line] and so forth) do not seem to check whether [channel->fd] is minus one before trying to read. This means that it can attempt to read from fd -1, causing "bad file descriptor". (Thankfully I think it always uses -1, so there's no problem with a file descriptor being closed and reopened onto something else.)

The fix is presumably to add the check as to whether [channel->fd == -1], but I'm not sure of all the potential ramifications of such change.

Comment author: @dbuenzli

This means that it can attempt to read from fd -1, causing "bad file descriptor".

Which is reported as a Sys_error "Bad file descriptor" (at least on osx) so I fail to see the problem here.

Comment author: @mshinwell

Ah yes, I failed to notice that the error text is indeed wrapped in Sys_error :) In which case, I think you're right, the semantics appears to be as per the documentation.

Comment author: @mshinwell

(Please re-open this if someone disagrees)