"'stty' is not recognised"

[bradrn]

General summary/comments

Sometimes on Windows 10 running a stack command results in the output 'stty' is not recognized as an internal or external command, operable program or batch file. This is reproducible when using eshell in Emacs, but occurs sporadically in other situations as well; I will reply to this issue if I find any other way to reproduce this problem. Most troublingly, this issue stops Intero from working as well, as for some reason it aborts the install when the unexpected message is found.

Steps to reproduce

1. Open Emacs with emacs -q (to negate the effects any init file could have).
2. Run M-x eshell RET to start eshell.
3. Using eshell, run stack exec -- echo "Test". (Or any other stack command, but this is a simple and reliable way to demonstrate this bug.)

Expected

Only Test is printed.

Actual

The following is printed:

'stty' is not recognized as an internal or external command,
operable program or batch file

(EDIT: The above originally had the name of a Turkish politician copied into the error message, Why I don’t know; I don’t usually have anything to do with Turkey. I suspect I was using his name to test diacritic support in an unrelated program, and accidentally copied his name into the message above. Sorry if it caused any confusion.)

Stack version

~ $ stack --version
Version 2.1.1, Git revision f612ea85316bbc327a64e4ad8d9f0b150dc12d4b (7648 commits) x86_64 hpack-0.31.2

(I suppose I should take this opportunity to mention that the message about stty does not occur when stack --version is run; I suspect this is because --version just prints a hardcoded message.)

Method of installation

Official binary, downloaded from stackage.org or fpcomplete's package repository

[bradrn]

Update: I also get this error message when I run ghcid.

[bradrn]

Well, it took some time, but I finally figured out what’s causing this error. Since 9b3419082b0bd33c57fd7ee33b8a141ce57e5435, stack relies on the terminal-size package for terminal size detection. On Windows, this package in turn relies on the Windows API GetConsoleScreenBufferInfo function for this functionality. If this fails, as it does on Cygwin and MSYS, it falls back to stty. As it turns out, this function also fails when using the Emacs Shell and other situations where this Windows API function doesn’t work — so it attempts to run stty and fails. I can think of three approaches for fixing this:

1. Revert 9b3419082b0bd33c57fd7ee33b8a141ce57e5435 and go back to the old method of detecting terminal size
2. Figure out some way of suppressing error messages from terminal-size
3. Post an issue on the terminal-size GitHub page to add support for Emacs Shell

This also gives us a workaround (sort of), in the form of copying over stty from the MSYS installation stack contains. Here’s the commands I used to copy stty to a directory in my PATH:

> stack exec -- where stty
C:\Users\bradn\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\bin\stty.exe
> copy C:\Users\bradn\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\bin\stty.exe .
> copy C:\Users\bradn\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\bin\msys-2.0.dll .
> copy C:\Users\bradn\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\bin\msys-iconv-2.dll .
> copy C:\Users\bradn\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\usr\bin\msys-intl-8.dll .

(Note that the exact path will be slightly different for other people.)
Unfortunately, this is only half a workaround: it gets rid of the 'stty' is not recognized as an internal or external command, operable program or batch file error, but creates a new error, which is caused by stty itself:

stty: 'standard input': Inappropriate ioctl for device

Luckily, it’s enough of a workaround for Intero to start working again: it no longer crashes itself when a Haskell file is loaded (which meant I couldn’t even open any Haskell file in Emacs). Completion and syntax checking still don’t work though, so we’ll have to keep looking for either a solution to this bug or another workaround.

[bradrn]

Well, I finally managed to fix this bug by submitting biegunka/terminal-size#13! You can build a custom version of stack with this bug fixed using the following instructions:

1. Clone stack and cd into the project directory.

2. Add the following lines to the end of stack.yaml:

   extra-deps:
   - git: https://github.com/bradrn/terminal-size
     commit: 591033712003b58f8c61dba0fc60e95439df9c9b

   (This loads my custom version of terminal-size containing the commit from the PR)

3. Run stack install to replace your global stack installation with this one.

After this the error should disappear and Intero should work properly again.

[bradrn]

So, after a week of waiting I’ve given up on that PR being merged into terminal-size, so I’ve just created #4968, which should fix this issue in a different way. Instead of modifying terminal-size, #4968 simply wraps the call to size in hSilently [stderr], which inhibits output to stderr.

[MattLamari]

That Terminal-Size project doesn't seem to see a lot of action - may be worth requesting a workaround to this call be put directly into Stack, given how disruptive this is to anyone doing Emacs/Intero work.

[bradrn]

@MattLamari That’s basically what we’ve been discussing in the PR.

[tuomohopia]

I'm getting this same error on haskell-ide-engine on vscode, Win10.

What's the way to go around this now?

[svenpanne]

IMHO stack should just absorb terminal-size into its source tree and apply a fix there, see #4968 (comment).

[bradrn]

Well, Intero has just reached end of life. Not sure yet how it will affect this issue, but I think it’s worth noting that Intero was the only application I know of which this issue broke.

[svenpanne]

Well, Intero has just reached end of life. Not sure yet how it will affect this issue, but I think it’s worth noting that Intero was the only application I know of which this issue broke.

Well, nothing changed, you missed a comment and this issue is still a kind of show stopper: #4901 (comment) mentions that it affects the alternative for intero, too.

Can we somehow bump the priority of this issue? It really affects people and a relatively simple fix is known (#4968 (comment)). Or as a temporary alternative: The commit which introduced the terminal-size dependency should be reverted: If I see it correctly, it just fixed a minor aesthetical issue and introduced a severe bug on the way, not a very good trade-off...

[bradrn]

Well, nothing changed, you missed a comment and this issue is still a kind of show stopper: #4901 (comment) mentions that it affects the alternative for intero, too.

Oh dear… I did miss that. This issue is more important than I thought! (Although I wouldn’t call HIE the alternative for intero; surely that would be ghcid or haskell-mode.)

Can we somehow bump the priority of this issue?

That would certainly be nice! But unfortunately I don’t know of anyone who would be in a position to do that.

A relatively simple fix is known (#4968 (comment))

But has this fix been tested yet? Can you try implementing this on your own fork of stack and seeing if this works?

The commit which introduced the terminal-size dependency should be reverted: If I see it correctly, it just fixed a minor aesthetical issue and introduced a severe bug on the way, not a very good trade-off...

That would be a nice option as well, but again, I’m not sure who would be in a position to do this…