Skip to content

GHCi does not fail when it is called with `-e` and a command fails

Summary

GHCi's -e flag does not behave as it should be expected with commands (starting with :). At the moment in ghc/GHCi/UI.hs there is no way (except for triggering an exception which is not the best solutions in many cases) for a special command to make GHCi abort and exit with an error. This also causes inconsistent behavior with some commands such as :load as already documented in #17560 (closed): while :load blah throws an exception that makes GHCi exit with 1, :load Blah does not trigger an abort because, although loadModule at ghc/GHCi/UI.hs:1836 returns Failed, this information gets ignored and the commands returns () anyway (at loadModule_). Special commands at ghc/GHCi/UI.hs:176-238 have type String -> GHCi () and this obviously does not encompass the case when the command may fail.

Steps to reproduce

The following commands all ought to exit with 1 while all of them exit with 0:

  • ghci -e ':abcde'
  • ghci -e ':set +XAbcde'
  • ghci -e ':!/bin/false' (I think that when a shell command returns nonzero, GHCi should return 1 to indicate that the command failed)
  • ghci -e ':load Abcde'
  • and so on for every command that may fail

Expected behavior

As reported above.

Environment

  • GHC version used: 8.8.1
Edited by Tito Sacchi
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information