This project is mirrored from https://github.com/haskell/process.
Pull mirroring updated .
- 02 Aug, 2014 1 commit
-
-
kgardas authored
-
- 30 Mar, 2014 2 commits
- 13 Jan, 2014 1 commit
-
-
Austin Seipp authored
Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
- 01 Dec, 2013 3 commits
-
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
This also tweaks Haddock comments & markup in "System.Process" while at it. Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
Otherwise, `cleanupProcess` may exit prematurely if trying to flush out data to the process' stdin handle even though the endpoint has already vanished, and fail to complete the cleanup process. See also 228297ec and #2233. Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 30 Nov, 2013 1 commit
-
-
Herbert Valerio Riedel authored
This is a follow-up to 79ae975a (addressing #2233) Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 29 Nov, 2013 3 commits
-
-
There is a potential deadlock with withCreateProcess in the case that there's an exception: cleanupProcess will try to hClose the various handles, but if another thread holds the Handle lock then that hClose will block. Takano Akio fixed the main case of this (in patch 32223a9a ) by terminating the process (before closing the handles) This works because terminating the process will eventually cause those other threads to finish and release the Handle lock, so we can hClose. However on Unix terminateProcess is not guaranteed to terminate the process since it uses SIGTERM, which can be handled or ignored. So we have to separately guarantee that the handles can be hClosed, and the simplest way to do this is to ensure that the thread reading from the handles get killed in the case there's an exception. So we change forkWait to withForkWait that will kill off the thread if the body gets an exception. Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Factor it out into an ignoreSigPipe util, and use it in both readProcess and readProcessWithExitCode. Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Now all the functions that call a process synchronously have the same behaviour. Previously just readProcess, readProcessWithExitCode did this, now callProcess and callCommand do too. If a thread running one of these functions gets an exception, including async exceptions (such as from timeout or killThread), then the external process gets terminated. Introduce a helper function to implement this behaviour. Currently it is not exposed to users, but that could be changed easily. Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 21 Nov, 2013 2 commits
-
-
Austin Seipp authored
Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
Austin Seipp authored
Win32 doesn't have defaultSignal. Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
- 20 Nov, 2013 10 commits
-
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
...and update changelog Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
...which is implied by Haskell2010; moreover add missing `BangPatterns` to `other-extensions`. Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
We don't want to do it immediately because some of the replacements have not been around for long. There's no hurry, can do it in a release or two. Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
And move the deprecated things (as per #2233) to the end, out of the way. Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Add callProcess, callCommand, spawnProcess, spawnCommand as per the design in #2233 (but not relying on any of the SIGCHLD stuff). Move the various pre-createProcess functions to a section at the bottom in the Haddock docs. Don't yet mark anything as deprecated. That can come later. Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
At least Cabal was using runGenProcess_, and the previous patches addressing #2301 changed its type already. So this adds a deprecated stub with the original type and the real function gets to have a less odd name. Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
This is a generalisation of the SIGINT-ignoring that system and rawSystem do, to allow it to be used via the general createProcess. For the gory details of SIGINT handling, see http://www.cons.org/cracauer/sigint.html We implement the 'WCE' method described there. That important feature was only available to system and rawSystem (mirroring the C system() behaviour). These functions are very limited and indeed deprecated, so we need this feature in general. In particular projects like Cabal are suffering because they cannot do this properly (or need horrible workarounds copy and pasting much of System.Process and using System.Process.Internals). The feature is available now via a new delegate_ctlc flag in the CreateProcess options record. The use of signal handlers is still a little hairy, but probably better than before (for situations where there were multiple concurrent calls to system/rawSystem). One thing to note is that waitForProcess and getProcessExitCode can now throw the UserInterrupt exception. This is all documented in the haddock docs (both a short description and also the excruciating details). Authored-by:
Duncan Coutts <duncan@well-typed.com> Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 14 Nov, 2013 1 commit
-
-
Duncan Coutts authored
So rather than a bitfield encoding, covering normal exit codes, signals and core dumps, we now simply use negative numbers for signal exit codes. We thus do not report core dumps by this mechanism. This encoding is a lot simpler to explain and use. It also happens to be the same encoding as Python's subprocess package uses. Anyone who cares about core dumps can still use the unix package.
-
- 12 Nov, 2013 1 commit
-
-
Herbert Valerio Riedel authored
This changes the exit code encoding from `(128+signum)` (as introduced via 54038240 ) to {{{#!hs if coredump then 0x8000 else 0 .|. signum `shiftL` 8 .|. exitstatus }}} in order to address the `process`-package part of #7229 Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 11 Nov, 2013 1 commit
-
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 01 Nov, 2013 2 commits
-
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 27 Oct, 2013 1 commit
-
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 24 Oct, 2013 1 commit
-
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 20 Oct, 2013 7 commits
-
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
This enables testing (or rather testing the packages builds) for all released GHC versions this package is supposed to work with. Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
This is a follow-up to e5fc2ac7 which removed NHC98 support but didn't consider the `process.cabal` file. While at it, this normalizes other parts of the cabal file and adds a `repository this` declaration. Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
The Hugs CPP conditionals in `System.Process.Internals` make little sense, as that module is only listed in `exposed-modules` when `impl(ghc)` and moreover, it's `import` in `System.Process` is guarded by an `#ifndef __HUGS__`. Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
Since ad1a5c88 `process` supports GHC>=7.2 (which implies `unix>=2.5`), therefore `MIN_VERSION_unix(2,5,0)` is always true. Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
Herbert Valerio Riedel authored
These automake aux files are not needed (anymore). Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-
- 02 Oct, 2013 1 commit
-
-
aljee@hyper.cx authored
The problem is in the exception handler in readProcess. When it receives an asynchronous exception, it tries to clean up by closing the pipes. However the attempt to close outh blocks because the reader thread (reading with hGetContents) is blocking on the handle. This fixes #8483. Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
- 29 Sep, 2013 1 commit
-
-
Peter Trommler authored
A comma in AC_CHECK_FUNCS prevented setitimer from being detected. Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
- 27 Sep, 2013 1 commit
-
-
Herbert Valerio Riedel authored
Supporting GHC 7.2 again was just a single `#ifdef`. Otoh, supporting GHC 7.0 would require reverting part of d10b168a . This also updates the build-dependancy version constraints to reflect the current reality. The code is `-Wall` clean for GHC 7.4 and later. Signed-off-by:
Herbert Valerio Riedel <hvr@gnu.org>
-