RE: Environment variable does not work (especially DARCS_EDITOR)

On 16 April 2005 20:41, Benedikt Schmidt wrote:
[ crossposted to libraries@haskell.org ] Tommy Pettersson
writes: A likely source of the problem can be that pico aborts if its stdin or stdout isn't a tty. I have that problem with nvi. If you run darcs 1.0.2 you can try and set DARCS_EDITOR to "pico /dev/tty". If you run a later build you may have to write a wrapper script like
#!/bin/sh pico /dev/tty
since the to-be-next stable darcs not always perform the redirection on the system call any longer.
Or, if this turns out to be the problem, and if you know how to make darcs do this redirection of stdin/out in a portable way, fix it in the darcs source.
The problem seems to be related to rawSystem and the ghc RTS (at least GHC 6.4). GHC sets stdin/stdout/stderr to nonblocking mode on startup and nvi doesn't like that. There is a comment in ghc/rts/RtsUtils.c that resetNonBlockingFd is called before exiting because leaving standard file descriptors in nonblocking mode confuses some shells.
module Main where import System.Cmd main = rawSystem "nvi" []
The test program works after applying the following patch to GHC that disables nonblocking mode after the fork and before the exec.
diff -u -r1.7 runProcess.c --- libraries/base/cbits/runProcess.c 27 Mar 2005 13:41:19 -0000 1.7 +++ libraries/base/cbits/runProcess.c 16 Apr 2005 19:08:52 -0000 @@ -62,6 +62,10 @@ dfl.sa_handler = (void *)quithandler; (void)sigaction(SIGQUIT, &dfl, NULL); } + + resetNonBlockingFd(fdStdInput); + resetNonBlockingFd(fdStdOutput); + resetNonBlockingFd(fdStdError);
dup2 (fdStdInput, STDIN_FILENO); dup2 (fdStdOutput, STDOUT_FILENO);
I'm not sure how to handle that in darcs without copying/reimplementing the parts of System.Cmd we need.
If we did this, we would also need to re-enable non-blocking mode after the rawSystem completes. Also, this doesn't work well if runProcess is used and the Haskell program continues to run while the subprocess is executing, because the O_NONBLOCK flag is shared between parent and child. So I suggest doing this for System.Cmd.{system,rawSystem} only. Cheers, Simon

Simon Marlow wrote:
The test program works after applying the following patch to GHC that disables nonblocking mode after the fork and before the exec.
If we did this, we would also need to re-enable non-blocking mode after the rawSystem completes. Also, this doesn't work well if runProcess is used and the Haskell program continues to run while the subprocess is executing, because the O_NONBLOCK flag is shared between parent and child.
Presumably the Haskell program won't like it very much if the spawned
program disables O_NONBLOCK itself?
Is there a reason (other than performance) why the use of O_NONBLOCK
can't be replaced with calling select/poll before accessing the
descriptor?
Is non-blocking I/O only necessary if you need explicit concurrency?
Or do the runtime or critical libraries require it?
--
Glynn Clements

Sorry for taking so long to reply. On Tue, 2005-04-19 at 11:36 +0100, Simon Marlow wrote:
module Main where import System.Cmd main = rawSystem "nvi" [] [ patch calling resetNonBlockingFD in runProcess ] If we did this, we would also need to re-enable non-blocking mode after
On 16 April 2005 20:41, Benedikt Schmidt wrote: the rawSystem completes. Also, this doesn't work well if runProcess is used and the Haskell program continues to run while the subprocess is executing, because the O_NONBLOCK flag is shared between parent and child.
I didn't think about the flags beeing shared between parent and child. I tried using setFdOption first, but didn't see that rawSystem sets stdin back to blocking mode when stdin is evaluated. This works for me now with ghc-6.4: main = do stdin `seq` return () bracket (setFdOption stdInput NonBlockingRead False) (\_ -> setFdOption stdInput NonBlockingRead True) (\_ -> rawSystem "nvi" [])
So I suggest doing this for System.Cmd.{system,rawSystem} only.
Would something like that be safe for system and rawSystem if all arguments where forced before the setFdOption? If there are several threads? Benedikt
participants (3)
-
Benedikt Schmidt
-
Glynn Clements
-
Simon Marlow