Re: [PATCH] Improve Windows tty/pty detection

[Pavel Fedin]

On 15.07.2023 18:55, Thomas Dickey wrote:
> I'm aware that the development shells for MinGW and MSYS2 use ncurses, 
> but
> a) haven't had a problem running ncurses applications in the MSYS2 development
>     shell (I've been using ded and vile in that for several years).
 Me neither. The problem can only be seen in MinGW shell, not MSYS
> >   The way to go is to prefer using API driver whenever possible. Since Aug
> > 2019 ConPTY support has been integrated into Cygwin, and MinGW as a
> > consequence; see
> > https://github.com/mintty/mintty/issues/56#issuecomment-526170062 .
> That appears to mention MSYS2 rather than MinGW.
 Yes, indeed. But here's one catch. MinGW in fact also runs bash; and 
bash only lives within MSYS environment. Because it expects all pathes 
to start with '/' and not drive letter; and common shell scripts rely on 
UNIX command line tools, which also mostly live in MSYS environment. So 
MinGW environment is in fact hybrid. It uses msys.dll to support scripts 
(like autoconf and friends), which end up calling MinGW gcc, which is 
targeted at plain WinAPI, no mingw/msys involved. "MSYS" environment has 
own gcc version, which is targeted at this very environment, so the 
whole thing is self-hosted.
> > 1. MinGW consists of two environments: MinGW and MSYS. MSYS is full
> ...but you're describing their development shells.
> Neither of those use Console API.

 Yes, but you may run a native Windows .exe file, which does use 
console API, from within these shells. The shell understands what kind 
of binary it is; and if it's plain Windows binary, it will translate 
known environment variables (like PATH), and execute the binary. Then 
the binary uses WinAPI as usual.

 The actual case when i hit this problem is:

 I am developing a ESP8266 project, using their latest official SDK: 
https://github.com/espressif/ESP8266_RTOS_SDK . The SDK wants MinGW 
environment to run; it uses gcc as a target compiler. It rejects MSYS.

 A part of the SDK is a "menuconfig" program, which is actually a 
KConfig, borrowed from Linux. So, when i type "make menuconfig", this 
KConfig program is built using host gcc and run. Since i am in MinGW, 
the program ends up living on top of WinAPI, not on top of msys.dll. And 
it uses ncurses to draw its interface. And if you just run it in vanilla 
MinGW shell, you get the issue. You see a garbled screen, unless you 
unset the TERM variable. Or set it to "#win32con".

 I find it tedious to manually unset TERM every time i want to run 
this. And this is not only KConfig, this could be any other 
ncurses-based program, which is compiled using MinGW gcc (not msys 
gcc!), and then run from within the same shell.

> I think that's in the README:
> https://github.com/ThomasDickey/ncurses-snapshots/blob/ffbd62551a2a7afb337016e361f83e573155be8e/README.MinGW#L63
> Beginning with build 17763 (Fall 2018 update), Windows 10 supports 
ANSI escape
> sequences (Virtual Terminal support). If ncurses detects this or a later
> Windows 10 version, the interpretation of the implicit TERM setting 
(which
> means: TERM is not set or empty) changes. In this case, TERM is to be 
assumed
> to be "ms-terminal" and ncurses acts using the regular terminfo based 
driver,

> thus acting like a regular Terminal we all know from UNIX like 
environments.

 Sorry, where's the code which does this ? I could not see it. Is it a 
part of the new experimental driver ?