From 1803 to 1809, pty excretes ANSI that results in Emacs unkillable Console Window Host procs

[greghendershott]

I evaluated using WSL with Ubuntu Bionic and its Emacs 25.2.2 (via sudo apt install emacs25), for a workflow that includes running some Windows executables from Linux Emacs.

I tried this on a spare laptop, with Windows 10 Home, 1803, 17134.590.

Things worked well enough that I bought a new laptop for this workflow.

Unfortunately it came with Windows 10 Pro, 1809, 17763.348. 😭

---

Steps:

• In Linux Emacs 25.2.2, do M-x shell.
• Enter ipconfig.exe (for example -- or any Windows console executable, AFAICT).

Result:

• ^[[6n is displayed. The shell process in unresponsive, "hung" (although Emacs isn't).
• The usual commands like C-c C-c (comint-interrupt-subjob) and C-c C-\ (comint-kill-subjob) have no effect.
• If you C-x k to kill the *shell* buffer, it warns there's a process running.
• Enter yes to kill anyway.
  • Result:
    • The Emacs buffer is killed.
    • Emacs does kill the /bin/bash --noediting -i process -- you can see it gone from doing a ps auwx.
    • But Task Manager still has a Console Window Host process -- and it's using 25% CPU, and can't be killed without logging out or restarting Windows.
• Repeat this a few more times and you'll accumulate more of these Console Window Host processes.
• Logout or restart Windows.

Ouch.

---

If instead you try M-x ansi-term, and enter ipconfig.exe, then it displays

0;C:\Windows\System32\ipconfig.exe
                                  Windows IP Configuration                              
                                                                                        
                                                                                        
Ethernet adapter Ethernet:                                                              
        ... snip ...

The 0;C:\Windows\System32\ipconfig.exe and newline/indent is weird.

At least it doesn't hang. But using ansi-term isn't a suitable work-around for shell-mode. And, many, many things in Emacs open a pty and work fine when TERM="dumb". For instance, many Emacs modes derive from comint-mode like shell-mode does -- especially modes to run a programming language REPL or interpreter.

---

Again: All of this "just-works" with 1803. Something changed after, by 1809.

---

Sort-of-work-around: If in your init.el you set process-connection-type to nil -- meaning pipe instead of pty -- then things like M-x shell will print e.g.

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

Which is disconcerting but you can then enter ipconfig.exe and it will work fine.

(However, if some code doesn't use the default and locally binds process-connection-type back to t for something it does? Bad times.)

[greghendershott]

By the way, I thought about submitting this instead at https://github.com/Microsoft/console/issues. I didn't because this seems to be about running a Windows executable from WSL and not using the Windows console application.

But I don't know how you view it internally, or even really what is going on under the hood. Maybe the console folks changed how WSL runs win exes, in order to support the console, and broke other scenarios?? Anyway I'm happy to cross-post the issue if you prefer.

[benhillis]

@greghendershott - It is likely this is console related. When Windows processes are launched, we create a Windows pseudoconsole under the hood. @bitcrazed, would you like an issue filed in the console GitHub?

[smzht]

It can be avoided by the following method.

$ exec > /dev/tty

[therealkenc]

The hang does reproduce on WSL2 21370. Odd it allegedly "just worked" in 17134.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!