New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

failing tty checks with conemu-cyg-32.exe #1240

Open
Vampire opened this Issue Aug 29, 2017 · 10 comments

Comments

2 participants
@Vampire

Vampire commented Aug 29, 2017

Versions

ConEmu build: 170819 x64
OS version: Windows 10 x64
Used shell version (Far Manager, git-bash, cmd, powershell, cygwin, whatever): GNU bash, version 4.4.12(3)-release (i686-pc-cygwin)

Problem description

When starting Cygwin terminal by invoking conemu-cyg-32.exe, the tty-checks of programs seem to be broken. If you e. g. start any Gradle build from plain Bash, you see progress information and colors. If you start it from conemu-cyg-32.exe, you don't. Interestingly the same happens in "Git Bash" from Git for Windows. There also no progress and colors are shown.

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Aug 29, 2017

I think you chose wrong site to request help on Gradle config.
The only thing I can say, connector emulates posix tty properly, just because it's built on top of cygwin tty API.

Perhaps your Gradle don't know TERM variable ConEmu exports. But the same value is exported by many other terminals.
Report to Gradle.

@Vampire

This comment has been minimized.

Vampire commented Aug 29, 2017

Well, actually it uses a native library to determine whether the console is attached to a terminal or not. The project is https://github.com/adammurdoch/native-platform, the corresponding code that returns false is https://github.com/adammurdoch/native-platform/blob/master/src/main/cpp/win.cpp#L404-L419.

@Vampire

This comment has been minimized.

Vampire commented Aug 29, 2017

I also reported it at adammurdoch/native-platform#26 now in case it is more a problem of the detection process, but I'm still not sure which side is causing this.

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Aug 29, 2017

I think you misunderstood the tty detection.
The code mentioned above is a detection if the current input/output handles are handles to WinAPI conhost handles.
Obviously when you run connector (or mintty) the current handles are not WinAPI capable. They are "true" posix tty handles. That means that application must use ANSI sequences for communication with terminal API.

@Vampire

This comment has been minimized.

Vampire commented Aug 30, 2017

Ah, so it IS the detection that is erroneous, because it does not do the correct checks when run in the Connector or in Git Bash and thus msys, right? Can you tell me how the detection has to be done properly?

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Aug 30, 2017

What do you want to check? If the terminal supports ANSI on Windows?
If so, one may check for environment variable ConEmuANSI or ANSICON.
https://conemu.github.io/en/ConEmuEnvironment.html
When ConEmuANSI is ON defined, application is allowed to write ANSI sequences.

@Vampire

This comment has been minimized.

Vampire commented Aug 30, 2017

No, the check tries to determine whether a terminal is attached to the streams. If a terminal is attached, there is e. g. progress information and colors shown. If no terminal is attached, e. g. stdout is piped to another command, no progress information is displayed and no colors are shown.

Besides that, a ConEmu specific solution is probably not the best solution if the reason it is not working correctly is the same as for Git Bash and there could be a way used that works for this situation.

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Aug 30, 2017

Application which was not built with cygwin/msys can't determine if there is POSIX tty on pipe handles.
Well, they may load cygwin1.dll or msys-2.0.dll and call their functions but that is VERY complicated.
I can suggest solutions for ConEmu only.

Perhaps it would be better to implement some switch in your tool (e.g. --color) to force progress and colors in any terminal.

Hmm... Also I may try to redirect API calls to "real" handles, but all processes spawned from connector are free from ConEmuHk and you shall run them via ConEmuC -c ... to get them detoured.

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Aug 30, 2017

BTW, there is command ConEmuC -IsRedirect which returns 1 as errorlevel if CONOUT is redirected, 2 if not.
But I'm not sure if it works in connector, I think it doesn't now.
Anyway, this is a solution for ConEmu only.

@Vampire

This comment has been minimized.

Vampire commented Aug 31, 2017

It is not my tool, I'm just a user and sometimes contributor. Just searching for a solution I could suggest and you sounded like you could have an idea. :-)

@Maximus5 Maximus5 added this to To Do in Inspection via automation May 28, 2018

Maximus5 added a commit that referenced this issue Jun 8, 2018

gh-1240: For those who want to run WinAPI console applications from P…
…OSIX layer: `ConEmuC -std -c your-command`.

  When you run connector (or wslbridge) console handles are set into POSIX mode,
  and only applications directly compiled for this mode will behave as they are in tty.
  In other words, if you run ‘ConEmu/cygwin-connector/bash’ and try to start Python
  outside of cygwin folder (e.g. downloaded from https://www.python.org/downloads/),
  the Python will not think it was started in terminal, because it was not linked
  with cygwin1.dll!
  The command `ConEmuC -std -c python` tries to reinitialize console to work
  like python was started from cmd.

@Maximus5 Maximus5 added this to To Do in ConEmu via automation Jun 12, 2018

@Maximus5 Maximus5 removed this from To Do in Inspection Jun 12, 2018

@Maximus5 Maximus5 moved this from To Do to Ready for Testing in ConEmu Jun 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment