On Wed, 13 Dec 2006, John Goerzen wrote:
[... re System.Cmd.Utils]
It could go under System.Posix perhaps. It relies quite heavily on functionality provided by the unix package and the System.Posix.* tree.
Take a look at the source at:
http://software.complete.org/missingh/browser/src/System/Cmd/Utils.hs ... Comments?
Reminder for those just joining the thread, the API we're discussing is http://software.complete.org/missingh/static/doc/System-Cmd-Utils.html
Use of executeFile means you inherit its ideas about the argument list. Unless it has been fixed, you can't specify argv[0]. That's fine until you want to specify argv[0] for some reason, then it's a gratuitous compromise to the C interface. If there isn't any special issue that makes execve(2) awkward to use from Haskell, maybe you could use it and avoid executeFile. Otherwise, since argument list is not per man 2 execve, the difference needs to be documented for functions that take an argument list. I find the name "PipeHandle" confusing, since it turns out there's no open file pointer or any such Handle-like property. pipeLinesFrom seems gratuitous, I mean, can't people use `lines'? pOpen3Raw 3 4 4 ... is bad just because you'll close 4 twice? It seems like something people are bound to do anyway, and not a huge problem to support. For pOpen3, I think I would just say "dup unit 0 from this fd", etc., rather than "send stdin to this fd" which makes sense only if this fd really is a pipe. And of course I'd change "redirecting things to pipes" to "redirecting standard file descriptors", since it will work fine whatever kind of device the fd may actually be. It's clearer to use "0" as the name for UNIX standard input (and 1, 2 for output and error), and explain separately if you think that won't be obvious to the audience.
From what I have seen of these pipe functions in other contexts, the hairy stuff happens when people get a process with pipes on both ends, and try to feed data in one end and milk it out on the other. That invariably causes some kind of deadlock. If the API doesn't directly support it, that would probably be just as well.
Well, you asked for comments! Donn Cave, donn@drizzle.com