[Haskell-cafe] runInteractiveProcess and hGetLine on Windows

David Roundy droundy at darcs.net
Wed May 7 16:38:20 EDT 2008

On Wed, May 07, 2008 at 09:24:46PM +0100, Duncan Coutts wrote:
> On Wed, 2008-05-07 at 08:46 -0700, David Roundy wrote:
> > On Wed, May 07, 2008 at 08:33:23AM -0700, Bryan O'Sullivan wrote:
> > > David Roundy wrote:
> > > > This is the correct behavior (although it's debatable whether kpsewhich
> > > > should be outputting in text mode).
> > > 
> > > I think it would be more accurate to say that runInteractiveProcess has
> > > an inadequate API, since you can't indicate whether the interaction with
> > > the other process should happen in text or binary mode.
> > 
> > I don't see any reason to support text mode.  It's easy to filter by hand
> > if you absolutely have to deal with ugly applications on ugly platforms.
> If it was only Windows' silly line ending convention I'd be tempted to
> agree but we probably want to distinguish text and binary handles
> anyway. You get Chars out of a text handle (with some string
> ed/decoding) and bytes out of a binary handle. In that case, default
> line ending convention is just another thing to throw in with the text
> encoding conversion.

But that's a feature that was only added in a very recent ghc, right?  I
consider it an ugly hack to work around the fact that we have no system for
dealing with file encodings.  I'd rather consider text mode handles to be
an ugly workaround for an ugly system, and have a clean solution for
unicode (e.g. one that allows for the reading of files that are not in the
locale encoding).  I certainly wouldn't want to be forced to live with DOS
line endings just to generate unicode output.  Fortunately, darcs doesn't
do unicode (or need to) or text mode, so I personally am pretty safe from
this feature.


More information about the Haskell-Cafe mailing list