on master help sign in
Micro cleanup of pull request #233
0b705d7Jasper Van der Jeugt
src/Hakyll/Core/UnixFilter.hs+12−4
@@ -19,7 +19,7 @@ import System.Exit (ExitCode (..))
19import System.IO (Handle, hClose, hFlush, hGetContents,
19import System.IO (Handle, hClose, hFlush, hGetContents,
20 hPutStr, hSetEncoding, localeEncoding)
20 hPutStr, hSetEncoding, localeEncoding)
21import System.Process
21import System.Process
22−import System.Info
22+import qualified System.Info as System
23
23
24--------------------------------------------------------------------------------
24--------------------------------------------------------------------------------
25import Hakyll.Core.Compiler
25import Hakyll.Core.Compiler
@@ -105,9 +105,17 @@ unixFilterIO :: Monoid o
105 -> i
105 -> i
106 -> IO (o, String, ExitCode)
106 -> IO (o, String, ExitCode)
107unixFilterIO writer reader programName args input = do
107unixFilterIO writer reader programName args input = do
108+ -- The problem on Windows is that `proc` is that it is unable to execute
109+ -- batch stubs (eg. anything created using 'gem install ...') even if its in
110+ -- `$PATH`. A solution to this issue is to execute the batch file explicitly
111+ -- using `cmd /c batchfile` but there is no rational way to know where said
112+ -- batchfile is on the system. Hence, we detect windows using the
113+ -- `System.Info` module and then instead of using `proc` to create the
114+ -- process, use `shell` instead which will be able to execute everything
115+ -- `proc` can, and this can deal with batch files as well.
108− let pr = if os == "mingw32"
116+ let pr = if System.os == "mingw32"
109− then shell $ unwords (programName : args)
117+ then shell $ unwords (programName : args)
110− else proc programName args
118+ else proc programName args
111
119
112 (Just inh, Just outh, Just errh, pid) <-
120 (Just inh, Just outh, Just errh, pid) <-
113 createProcess pr
121 createProcess pr