David Roundy wrote:
The only thing I'd like to check on that I can't tell about is whether passing stdin and stdout to runProcess will behave "correctly". Some programs (e.g. gpg) can figure out how to get control of the tty by themselves (to ask for passwords in the case of gpg),
Programs which read passwords generally open the controlling TTY, directly, i.e. open("/dev/tty", O_RDONLY); this is quite distinct from stdin/stdout.
but others (some versions of vi) will fail if their stdin and stdout correspond to a tty.
Correspond, or don't correspond?
It would be nice to be able to run "user-interactive" commands such as text editors in a safe and consistent manner.
Are you referring to the case where you let the child inherit the parent's stdin/stdout, and suspend the parent for the duration of the child (e.g. system("$EDITOR ..."))? Or running the child on a slave pseudo-tty?
I'm not clear from your code whether there will be a problem with passing stdin and stdout to runProcess. If the process closes stdin, will it be closed for me?
I would expect so; once a descriptor is close()d, you can't "unclose" it.
If the process changes the buffering of stdin, will that change it for me?
*Buffering* involves user-space memory, so it can't be preserved across an exec() call. However, GHC's hSetBuffering doesn't just set the buffering; it also messes with the TTY settings. As those are per-device rather than per-process, any changes would inevitably affect the child (unless runProcess explicitly undoes the changes when passed a Handle which corresponds to a TTY). Realistically, the hSetBuffering misfeature should be discarded if Haskell is meant to be useful for anything beyond "simple, stupid programs".
Enquiring minds want to know! :)
In view of the smiley: was this an actual request for information, or
a way of pointing out that you need to define the semantics in order
for the function to be of any real use?
--
Glynn Clements