posix, POpen, ghc 6.5

[Simon Marlow]

Frederik Eaton wrote:

> On Mon, Jan 09, 2006 at 10:11:23AM +0000, Simon Marlow wrote:
>
>>popen and the posix package have been deprecated for quite some time now.  If you're having 
>>problems with System.Process, please submit bug reports - there's one outstanding bug that I'm 
>>aware of, but it doesn't seem critical: http://cvs.haskell.org/trac/ghc/ticket/431. 
> 
> That seems like a critical bug to me. What if I want to use Haskell to
> write a daemon which closes its standard input, yet uses a library
> based on runInteractiveProcess? Do I have to contact the library
> authors and have them rewrite their library for every new ghc release
> (since they would have had to have been using popen until now), or
> should I just settle with things not functioning?

If you look through the comments, you'll see we partially fixed the bug. 
  Just closing stdin works fine, but if you close stdout or stderr as 
well, then things go wrong.  If someone says this is critical for them, 
then we'll bump the priority.

> Here is the output of a small test program (attached). If I compile
> this particular example, then it works, but when I use 'runghc' it
> doesn't. I seem to remember it being broken while testing in ghci as
> well. This is why *I* am using 'popen'. Have I made a mistake?
> 
> $ ./test-proc.hs  
> here0
> here1
> here2
> here3
> here4 [ here it hangs and i press ^C ]
> runghc: waitForProcess: interrupted (Interrupted system call)
> 
> [1]$ which runghc  
> /usr/bin/runghc
> $ runghc --version
> runghc: syntax: runghc [-f GHCPATH] [GHC-ARGS] FILE ARG...
> [1]$ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.4.1
> $ which ghc
> /usr/bin/ghc

Ah yes, this is because GHCi isn't compiled with -threaded.  Looks like 
we've found one more reason to do that.

> I vaguely remember hearing that POpen has been deprecated (where is it
> documented?), and I like the new interface which was been provided,
> but I think that the new interface should be stable and bug-free for
> at least a few minor versions before the POpen module is removed. And
> why not provide a compatibility wrapper? 

POpen hasn't been removed yet - you're testing out our development code, 
remember.  There will be at least one more stable release that contains 
POpen.

 > I don't see the point of forcing people to change working code.

There are quite a few reasons we have to do this, but #1 is lack of 
resources.  I'd love to keep each branch going for longer, but it takes 
more time than we have available.

Cheers,
	Simon