GHC dies silently with faulty preprocessor

This is perhaps a minor nuisance but I had to spend
quite some time to track down my bug. When ghc is given
a preprocessor which for some reason cannot execute
then ghc just dies silently without giving any
indication as to what the problem was. It would be nice
with a little message hinting at the problem on stderr.

Oh, and by the way, the -F flag doesn't have any
documentation. It is only mentioned together with -optF.

changed weight to 5

added Tbug Trac import labels

Logged In: NO 

This is on Windows, I presume?

On Linux, I get:

$ ghc -F -pgmF wibble -c hello.hs   
ghc-6.4: could not execute: wibble

Logged In: YES 
user_id=307552

Indeed, this is on windows. It happens very easily when
working on cygwin. It is very natural to use a shell script
as a preprocessor which is what I was trying to do. But
since ghc is a windows program it doesn't know what a shell
script is. Hence the failure.

closed

Logged In: YES 
user_id=48280

Fixed, thanks for the report.

mentioned in issue #9399 (closed)

reopened

changed the description

This is still an issue.

$ echo 'main = return ()' > hello.hs
$ touch wibble                          # The faulty preprocessor.
$ chmod +x wibble
$ ghc -F -pgmF ./wibble -c hello.hs     # Note: no error message.
$ echo $?                               # But the command failed.
1

This affects TEST=enum01 currently.

Compiling with -v shows:

*** Haskell pre-processor:
"./wibble" "hello.hs" "hello.hs" "C:\msys64\tmp\ghc3020_0\ghc3020_1.hspp"


Failed: "./wibble" "hello.hs" "hello.hs" "C:\msys64\tmp\ghc3020_0\ghc3020_1.hspp" ./wibble: runInteractiveProcess: invalid argument (Exec format error)

Trac metadata

Trac field	Value
Version	6.4 → 7.11
TypeOfFailure	- → OtherFailure
Resolution	ResolvedFixed → Unresolved
Operating system	- → Windows
Architecture	- → Unknown/Multiple

It seems the -pgmF flag is just plain broken on Windows (msys2). The following fails in the same way as wibble above:

$ echo 'cat $2 > $3' > preprocess
$ chmod +x preprocess
$ ghc -F -pgmF ./preprocess hello.hs
$ echo $?
$ 1

Oh, Phyx on #ghc says -pgmF requires a .bat file. Sure enough, then it works:

$ echo 'cat %2 > %3' > preprocess.bat
$ chmod +x preprocess.bat
$ ghc -F -pgmF ./preprocess.bat hello.hs
C:\msys64\tmp\test>cat "hello.hs"  1>"C:\msys64\tmp\ghc1556_0\ghc1556_1.hspp" 
$ echo $?
0

Still, I'd like to see an error message when preprocessing fails, without having to specify -v.

More specifically, I think the issue here is with the use of runInteractiveProcess, which ultimately calls CreateProcess on Windows. The problem is that processes created using CreateProcess must be known by the Windows loader. From the MSDN page.

"This module can be a Windows-based application. It can be some other type of module (for example, MS-DOS or OS/2) if the appropriate subsystem is available on the local computer. "

Since .py are not known by the system loader the call fails with Exec format error

I think there are two solutions:

• Specify cmd.exe or rather, whatever ComSpec is pointing to as the application and the preprocessor to run as the argument.
• Alternatively use ShellExecute instead of CreateProcess to start the preprocessors.

However both of them won't necessarily fix the tests that are failing, since that would require the .py extension to be registered to the python2 in msys.

Added a patch so it doesn't silently die.

Trac metadata

Trac field	Value
Test case	- → T365
Differential revisions	- → D1256

assigned to @Phyx and unassigned @simonmar

mentioned in commit b6f76b9a

closed

Merged.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

changed milestone to %8.0.1

Using ShellExecute would probably be the wrong thing to do in this instance. ShellExecute is the right thing to "execute" (or Open) a file in the same way as the "Shell" (e.g. Windows Explorer) would do. In other words, its a generic "open this file" mechanism, not something to run command line tools, which is what you really want here.