ghc -e sometimes spills control characters into its output

[int-e]

The behaviour depends on the TERM variable. For example,

# TERM=xterm ghc -e 'return ()' | od -a
0000000 esc   [   ?   1   0   3   4   h
0000010

Workaround: unset the TERM variable.

Analysis: Those control characters are emitted by libreadline on initialisation. They enable the terminal's meta mode.

[int-e]

proposed fix: Only initialise libreadline if ghc(i) is used interactively from a terminal.

[duncan]

I get this behavior with runghc too. It adds some control character to the end of the output. This makes it unusable in many scripting applications and breaks some testsuite tests. Again, setting TERM=vt100 or similar rather than "xterm" fixes it.

So when verifying the fix, test with runghc as well as ghc -e.

[int-e]

Replying to duncan:

I get this behavior with runghc too. It adds some control character to the end of the output. This makes it unusable in many scripting applications and breaks some testsuite tests. Again, setting TERM=vt100 or similar rather than "xterm" fixes it.

Good point. I tried that with my patch and it fixes that case as well, even when input is from a terminal.

[igloo]

Testsuite tests shouldn't be failing as we do

os.environ['TERM'] = 'vt100'

in driver/runtests.py.

[igloo]

Thanks for the report & patch! I've applied it to the HEAD and 6.8 branch.