|Maintainer||Matti Niemenmaa <email@example.com>|
Operations for piping data through multiple processes.
Whenever specifying a path to a process, explicitly specifying the current directory is recommended for portability. That is: use "./foo" instead of "foo", for instance.
On Windows, appending ".exe" to process paths is attempted if the invocation fails.
- pipe :: (Handle -> a -> IO ()) -> (Handle -> IO b) -> FilePath -> [(FilePath, [String])] -> a -> IO b
- pipe' :: (Handle -> a -> IO ()) -> (Handle -> IO b) -> [(FilePath, [String])] -> a -> IO b
- pipeString :: [(FilePath, [String])] -> String -> IO String
- handlePipe :: FilePath -> [(FilePath, [String])] -> Handle -> Handle -> IO ()
- filePipe :: FilePath -> [(FilePath, [String])] -> FilePath -> FilePath -> IO ()
- filePipe' :: [(FilePath, [String])] -> FilePath -> FilePath -> IO ()
Pipes the input, using the given writer and reader functions, through all the commands named, in the given working directory. Returns the result.
An exception is thrown if the list of programs is empty.
The writer function is called in a
forkIO'd thread, allowing this to be
lazy. That thread also calls
waitForProcess when done writing so that the
processes get terminated cleanly; this means that the runtime should be
multithreaded, or the call will block all threads and this function may
deadlock. (In GHC, compile with
SIGPIPE is ignored in the writer thread. Likewise, any IOExceptions are caught and ignored.
A convenience function for when you don't care about the working
pipe' uses ".".
Note that this is not merely a convenient frontend for
pipe and is
fundamentally different in the following ways:
- A null list of programs is allowed, in which case the contents of the input Handle are simply written to the output Handle.
- This function is not lazy and returns only when the writing has been completed.
A convenience function for
handlePipe. Opens the given files in binary