[Haskell-cafe] Re: On improving libraries: wanted list

[Donn Cave]

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 at drizzle.com