"ghc -e <invalid expression>" should return non-zero exit status

When GHC is run in expression-evaluation mode (i.e. with the "-e" flag) and the expression does not compile, GHC correctly prints an error message, but then exits with exit status 0. For example:

$ ghc -e foo

<interactive>:1:1: Not in scope: `foo'
$ echo $?
0

This is inconvenient for automated scripts that call GHC.

Trac metadata

Trac field	Value
Version	7.6.2
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added GHCi Tfeature request Trac import labels

GHC does what it was expected to do successfully. If it was to throw a non-zero code, it would indicate that there's something wrong with our usage of GHC or that it had some kind of other issue (and in fact we get ‘1’ when we try to compile a non-existent file).

GHC -e executes successfully and therefore exits with 0. It couldn't really care less about what happens during the session. For scripting, you probably want to write a Haskell program that does what you want and if it fails, throw whatever error code you want. It just isn't GHCs place to decide what it considers successful inside the session. Just my 2 cents.

Alternatively: does using runghc have the expected behavior?

GHC exits with status 1 if it encounters errors when compiling:

$ cat >Test.hs
askfljawioefjaiwojfeoawfe
$ ghc Test.hs 
[1 of 1] Compiling Main             ( Test.hs, Test.o )

Test.hs:1:1: Parse error: naked expression at top level
$ echo $?
1

It also exits with status 1 if the expression passed to "ghc -e" evaluates to bottom:

$ ghc -e "head []"
<interactive>: Prelude.head: empty list
$ echo $?
1

It seems odd that GHC would return 1 in both of those cases, but return 0 for "ghc -e <invalid expression>". Either the return value in one or both of those cases should be changed to 0, or the return value for "ghc -e <invalid expression>" should be changed to 1.

"runghc" behaves like a call to "ghc -e main <some file>". If there is an error in the expression "main" (i.e. if "main" is not in scope) it returns 0:

$ cat >Test2.hs
foo = 1 
$ runghc Test2.hs

Test2.hs:1:33:
    Not in scope: `main'
    Perhaps you meant `min' (imported from Prelude)
$ echo $?
0

But if there is an error in the text of the program itself, or if the program throws an exception when "main" is run, then it returns 1.

Trac metadata

Trac field	Value
CC	→ timmaxw@gmail.com

I agree with the original report. The man page says "**-e expr** Evaluate expr; see for details." (#3351...) If expr doesn't compile, then ghc has failed to evaluate it, IMO.

In reality I can pass arbitrary GHCi commands to ghc -e and it will run them; but the documentation doesn't say anything about this (either in the man page or in the user's guide).

Making ghc -e expr return 1 on compile error would also be consistent with other languages:

rwbarton@adjunction:/tmp$ bash -c if ; echo $?
bash: -c: line 1: syntax error: unexpected end of file
1
rwbarton@adjunction:/tmp$ python -c if ; echo $?
  File "<string>", line 1
    if
     ^
SyntaxError: invalid syntax
1
rwbarton@adjunction:/tmp$ perl -e if ; echo $?
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
255
rwbarton@adjunction:/tmp$ ruby -e if ; echo $?
-e:1: syntax error, unexpected $end
1
rwbarton@adjunction:/tmp$ ghc -e if ; echo $?

<interactive>:1:3: parse error (possibly incorrect indentation)
0

Attempting to take this on as my first ticket, ran into a couple problems. Essentially, using -e eventually calls into code common between GHCi and -e.

All the code for the following is in ghc/InteractiveUI.hs

Relevant control enters in runGHCi, in the case maybe_exprs block. Both cases of the block (one with -e arguments, the other with normal interpreting) then call runCommands, which eventually filters down to GhciMonad.runStmt, which eventually handles the source errors.

I am unsure of where to insert the logic to return a nonzero exit code, as putting it in GhciMonad/related would also affect normal GHCi.

Any tips?

Attached file 0001-Made-ghc-e-have-a-nonzero-exit-code-upon-failure-Tra.patch (download).

Patch file

Patch created and attached.

The test suite currently does not run on my Windows machine ("tee: standard output: Permission denied", followed by a hang), so I was unable to run the validation script.

As this is my first patch, please tell me what I did wrong :)

The patch looks ok. I would refactor it a bit, like this:

  when (not success) $ maybe (return ()) lift sourceErrorHandler
  runCommands' eh sourceErrorHandler gCmd

Don't forget to add a test to testsuite/tests/ghci. If the testsuite isn't working right now, search for a ticket about that, and if there isn't one, make one :-)

Patch reviewed, so leaving in the 'new' state.

Attached file 0002-Refactored-by-Simon-Marlow-s-suggestion.patch (download).

Refactoring patch

Attached file should_fail.zip (download).

Possible test files

Attached Simon's suggestion, and also some *possible* test files (which are, ironically, untested). I am not submitting them as a .patch because of their untested nature, and more of a "here's an example of what it might look like".

Also, I thought it might be better if they go into testsuite/tests/ghc-e, not ghci.

I'll go submit a ticket for the failing test suite now.

mentioned in commit 47024b63

mentioned in commit f783a6fc

closed

Done, thanks!

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

mentioned in issue #9905 (closed)

mentioned in issue #9916 (closed)

added Pnormal label

marked this issue as related to #18411 (closed)