run..Process borrow handles and escape argumentes - missing function?
Couldn't find a function which does this: use stdin/out/err of the main application and escapes the passed arguments automatically. I want to call "ssh user@host command" (runCommand :: String -> IO () ) command may contain redirection > so I would have to escape them. I don't want to have to do that I can pass a list of args to runProcess.. fine. So I can use runProcess ... (Just stdin) (Just stdout) ... to borrow the handles ? No: the comments say: -- Any 'Handle's passed to 'runProcess' are placed immediately in the closed state. That's not what I want. So I think there is still a function missing ? Cale has pointed me to hsh so I'll have a look there.. Marc
Marc Weber wrote:
Couldn't find a function which does this: use stdin/out/err of the main application and escapes the passed arguments automatically.
I want to call "ssh user@host command" (runCommand :: String -> IO () ) command may contain redirection > so I would have to escape them. I don't want to have to do that
I can pass a list of args to runProcess.. fine. So I can use runProcess ... (Just stdin) (Just stdout) ... to borrow the handles ? No: the comments say: -- Any 'Handle's passed to 'runProcess' are placed immediately in the closed state. That's not what I want.
So I think there is still a function missing ? Cale has pointed me to hsh so I'll have a look there..
Perhaps you just want to pass Nothing for the "Maybe Handle" arguments to runProcess, which means "inherit from the parent process"? Cheers, Simon
Perhaps you just want to pass Nothing for the "Maybe Handle" arguments to runProcess, which means "inherit from the parent process"?
Hi Simon. Once again you are right.
which means "inherit from the parent process"? This is not documented. I've missed it completely. When reading "Handle to use for ..." I assume nothing is used in the other case When reading "different handle used for ..." I would see it quite differently. But this seems to be my personal weakness.
When thinking about it again it doesn't make much sense to have no handle. The process is executed asynchronously. So when writing to stdout (either your application or the launched one) it might make sense to let both write to the same handle. But what happens if both want to read from stdin? The one who asks wether there is some input first will retrieve it? The extract from ghc-6.6-libraries/base/System/Process.hs: -- ---------------------------------------------------------------------------- -- runProcess {- | Runs a raw command, optionally specifying 'Handle's from which to take the @stdin@, @stdout@ and @stderr@ channels for the new process. Any 'Handle's passed to 'runProcess' are placed immediately in the closed state. -} runProcess :: FilePath -- ^ Filename of the executable -> [String] -- ^ Arguments to pass to the executable -> Maybe FilePath -- ^ Optional path to the working directory -> Maybe [(String,String)] -- ^ Optional environment (otherwise inherit) -> Maybe Handle -- ^ Handle to use for @stdin@ -> Maybe Handle -- ^ Handle to use for @stdout@ -> Maybe Handle -- ^ Handle to use for @stderr@ -> IO ProcessHandle -- ---------------------------------------------------------------------------- Proposal: "take the @stdin@, @stdout@ and @stderr@ channels for the new process. [ add: Otherwise inherit from parent process]" If this is changed it should be also changed in the runProcessPosix / runProcessWin32 comments.. Marc
Marc Weber wrote:
Proposal: "take the @stdin@, @stdout@ and @stderr@ channels for the new process. [ add: Otherwise inherit from parent process]"
Thanks, I've done exactly that. Cheers, Simon
participants (2)
-
Marc Weber -
Simon Marlow