Should cygwin/msys terminal connector require winpty?

[borekb]

The description of the connector ("This helper tool is an attempt to create the symbiont of POSIX enabled pty and WinAPI full-featured terminal.") sounds like it could perhaps present itself as a console to native Windows apps, not requiring winpty. But that doesn't seem to be a case, for example:

# mintty
$ node -p -e "Boolean(process.stdout.isTTY)"
false

# conemu-msys2-64 (Bash::Msys2-64 task)
$ node -p -e "Boolean(process.stdout.isTTY)"
false

# Windows Console
$ C:\msys64\usr\bin\zsh.exe --login -i
$ node -p -e "Boolean(process.stdout.isTTY)"
true

My end goal is to run mingw64 shell in ConEmu somehow, with as few trouble as possible. So far, a simple task defining just this:

set MSYSTEM=MINGW64 & set MSYS2_PATH_TYPE=inherit & C:\msys64\usr\bin\zsh.exe --login -i

seems to work fine, maybe even better than via a task running conemu-msys2-64.exe but I worry that this is a shallow observation. mintty is certainly problematic (will always require winpty) but I was assuming that conemu-msys2-64.exe was created to be the perfect middle ground. Is that the case?

[Maximus5]

Properly written WinAPI application may access console API because RealConsole exists when you run connector. But they never do, because they see inherited I/O handles and they have no intention to reopen them.

On the other hand, when you use connector, ConEmuHk is not injected into the cygwin/msys/wsl processes. Reason are either simple or obvious: speed, compatibility, binary difference. That means that ConEmu can't automatically switch POSIX to WinAPI modes.

But user can do that himself

$ ConEmuC.exe -std -c node -p -e "Boolean(process.stdout.isTTY)"

false

[borekb]

So for MSYS2 shells, are there substantial advantages of using

set MSYSTEM=MINGW64 & %ConEmuBaseDirShort%\conemu-msys2-64.exe -new_console:p C:\msys64\usr\bin\zsh.exe --login -i

over just

set MSYSTEM=MINGW64 & C:\msys64\usr\bin\zsh.exe --login -i

? I see visual differences like colors (the first reports TERM as being xterm-256color, the latter as cygwin and doesn't render my 243 prompt color as gray but rather white), and also the tab title is different (the former is e.g. ~, the latter is Borek@PC: ~). Other than that, starting zsh.exe directly seems to work fine so far.

[Maximus5]

If you want to bear multiple bugs of cygwin/msys console implementation, you may run zsh.exe directly.

https://conemu.github.io/en/CygwinMsys.html

[borekb]

I'm still trying to understand what the connector does to my environment. For example, while the following example doesn't make much sense in its own right, I'm not sure why the output is false when this is run from the standard Windows console tab:

$ %ConEmuBaseDirShort%\conemu-msys2-64.exe node -p -e "Boolean(process.stdout.isTTY)"
false

I guess that's what forcing me to use winpty when my ConEmu task starts with the connector. (The very ugly %ConEmuBaseDirShort%\conemu-msys2-64.exe winpty node -p -e "Boolean(process.stdout.isTTY)" returns true.)

[Maximus5]

I've already explained that above.

Connector emulates POSIX pty. Applications written exactly for that pty interface (cygwin/msys) are able to utilize full power of that pty view I/O handles they inherit from parent process. Applications written for WinApi can't utilize WinApi console functions on that handles obviously, they are not WinAPI capable.

There is absolutely no sense to run node via connector. There is no sense to run winpty from connector, coz ConEmuC does the work better.

[angshuman]

I have a few node commands that hang in ConEmu, however if run through winpty they work fine. I would say it would be nice to have the option of using it from a setting.