Stack exec incorrectly setting no buffering

[houli]

General summary/comments (optional)

A recent commit to stack has made it so that line buffering is turned off. This results in programs that are run by stack exec printing out control characters such as backspace instead of having the appropriate action on stdin. This can be seen clearly with a simple example such as cat vs stack exec cat. I first noticed this when using a program that made use of the standard getLine Haskell function.

Steps to reproduce

1. Run stack exec cat
2. Type some input
3. Attempt to use backspace to delete it
4. Compare results to just running plain cat

Expected

Backspaces and other control characters have their desired effect on the input.

Actual

Backspaces and other control characters are printed to the terminal.

Stack version

$ stack --version
Version 1.3.2 x86_64 hpack-0.15.0

Method of installation

Homebrew

[decentral1se]

Just triaging here, the relevant issue for the commit was #2702.

[geekosaur]

Note that this is an unintended side effect; some ghc versions back, ghc's Unix runtime started conflating NoBuffering with stty -icanon, which is convenient for users who don't know about termios but has this side effect if you want to use NoBuffering for some other reason.

[koterpillar]

Another consequence of this is Ctrl-D to signal EOF doesn't work either.

[mgsloan]

Interesting! Is there a way to resolve this while addressing the concern in #2702?

ghc's Unix runtime started conflating NoBuffering with stty -icanon

@geekosaur Do you know of a way to undo this conflation?

[geekosaur]

I don't know of one. You probably need to raise this with the ghc devs.

[andersk]

This affects not only programs run inside stack exec, but also programs run after stack exec!

$ stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
$ stack exec /bin/true
$ stty
speed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -imaxbel iutf8
-icanon

[geekosaur]

I think that's a missed edge case in ghc: termios gets reset if you switch from NoBuffering to BlockBuffering, but not if you switch to LineBuffering. (Found in #haskell the other day)

That one should probably be filed as a bug against ghc's base component.

[andersk]

I just pointed out in #2702 that the hSetBuffering calls do not even solve the problem reported there. They should really just be removed.

@geekosaur I cannot reproduce that in a simple test program. I think the problem is rather that the termios state cannot be reset if you prevent the runtime from cleaning up after itself by transferring execution to another program with execve (e.g. System.Posix.Process.executeFile or System.Process.PID1.run).