Open borekb opened 6 years ago
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
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.
If you want to bear multiple bugs of cygwin/msys console implementation, you may run zsh.exe
directly.
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
.)
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.
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.
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:
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:
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?