Hello. I've had the misconception that a file descriptor can be in a closed state. So the bug report was rather misguided - sorry for that.
Yes, what I actually want is to reset the stdin handle. Thanks for the hint to hDuplicateTo. This should be exactly what I need. I see that the thing which the file descriptor is connected to can be in an EOF state (end of file, other side of pipe closed...), whereas the file descriptor is still valid. This means that the Haskell Library Report actually demands for a closedness state to be maintained in the file handle, since EOF and closed handle are two different things (result in different exceptions etc). However, I'd still expect "hClose stdin" to actually close the file descriptor. I've taken a look at the hClose implementation. It's problematic not to actually close any standard file descriptors. For instance, some process might be reading the standard output of a Haskell program. When that program calls "hClose stdout", the process' read will block, rather than succeed with zero bytes read (EOF). The process won't notice that the program has finished outputting, until the program terminates. Imagine a case where a program outputs some status messages and then forks into demon mode, closing its standard file descriptors in order to detach itself from the terminal. I'm wondering if there's any particular reason for not actually closing the standard file descriptors. Greetings, Volker -- http://www.volker-wysk.de _______________________________________________ Glasgow-haskell-bugs mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
