8

I have written a script in haskell named testscript with the following code:

#!/usr/bin/env runhaskell

main = putStrLn "hello"

After making the script executable, I can run it using ./testscript. However, when I try to load the script with ghci (ie with :l testscript), I get the error 

target `testscript' is not a module name or a source file

If I rename testscript to testscript.hs, and try loading with ghci again, I get the error

testscript.hs:1:0:  error: invalid preprocessing directive #!
phase `C pre-processor' failed (exitcode = 1)

If I remove the shebang line it works fine. However it is tedious to have to add a .hs extension to the script, remove the top line, then remove the .hs extension and add the shebang line every time I want to try the script in ghci (which is pretty common everytime I want to make a change to it). Is there an easier way to do this?

I'm using ghc version 7.0.3 under Mac OS X 10.6.8

David Miani
  • 14,518
  • 2
  • 47
  • 66
  • At least on Linux, I don't get that last error about #!; I believe that if it's the first line, then ghci *should* accept it as a comment. – ivanm Nov 18 '11 at 05:51

1 Answers1

12

You can use the -x option to tell GHCi (or GHC for that matter) to treat all following files as if they had the specified extension.

There doesn't seem to be any way to specify this option from within GHCi (for use with :load), but a workaround you can use if you want this is to create a symlink with a .hs extension and load that.

Your second problem with the shebang line is caused by the C preprocessor being run on your source file for some reason (my old GHC install on Ubuntu does not do this). You can disable this by using the -XNoCPP option.

So for your case, this should work from the command line:

ghci -x hs -XNoCPP testscript
hammar
  • 138,522
  • 17
  • 304
  • 385
  • Thanks, that works. The reason the c preprocessor is run by default for me is I added :set -cpp in my ~/.ghc/ghci.conf. I didn't think about it until I remembered it wasn't default behaviour. – David Miani Nov 18 '11 at 06:06
  • 2
    @nanothief: Ah, that explains it. Another reason to prefer `LANGUAGE` pragmas for extensions. – hammar Nov 18 '11 at 06:10