On Thu, Mar 18, 2004 at 05:10:04PM +0000, Glynn Clements wrote:
David Roundy wrote:
but others (some versions of vi) will fail if their stdin and stdout correspond to a tty.
Correspond, or don't correspond?
Ineed, I meant to say "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 thinking of suspending the parent. Certainly having two programs try to read from stdin would be a nightmare.
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.
Hmmmm. So either we'd have to dup stdin and stdout before passing them, or hope that the program doesn't close them (and the duping *could* be done by runInteractiveProcess, if we wanted it to actively support this usage).
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).
Fortunately, as long as the *called* program behaves nicely (i.e. doesn't leave the tty in a different state than it started in), this shouldn't be a problem.
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?
It was an actual request for information. I'd really love to be able to just open an editor to let the user edit a file and have it just work, and currently I have no way of doing that which works with vi. On the other hand, if the answer is "No, don't pass stdin and stdout to runInteractiveProcess", it would still be a very useful call, it just wouldn't solve my vi problem. -- David Roundy http://www.abridgegame.org