cygwin-connector doesn't setup console window/mode

[gena01]

One of the issues that I've been running into lately is that when I use the conemu-msys2-64.exe instead of bash.exe I get into issues where various tools that check for windows console/tty fail and disable things like interactive prompt and color output.

This works fine when running through bash.exe

One of the more specific examples is ruby on windows. Simple testcase is to run "irb" that runs with ruby. in bash it should open interactive prompt. Inside cygwin-connector it goes into "inspect mode".

Also if you type: p STDOUT.isatty

You get false for cygwin-connector and true for bash.exe

This is how ruby checks for windows console: https://github.com/ruby/ruby/blob/trunk/win32/win32.c#L7222

[Maximus5]

What bash? What is your task contents?

[Maximus5]

You mention msys connector in one place and cygwin connector in other. The nature of connector is that you have posix terminal (pty) as result. That's the same as you run something in mintty or in real linux console. Native Windows applications shall reopen $CON handles to obtain Windows console API.

[gena01]

Ok, Maybe I am confused, so let me apologize. My setup is as following:

• ConEmu
• Git Bash
• conemu-msys2-64.exe (copied to Git\usr\bin folder where msys2.dll is)

I thought that conemu-msys2-64 was going to give me xterm-256color and is supposed to be a lighter/faster version than git bash.exe. Bash.exe is a complete shell that emulates the full "console"/tty environment and all tools that I use with it work fine, including ruby based ones.

However I ran into problems when I changed my startup task from Git::bash to Msys2 wrapper. What am I missing? Am i doing it wrong and I should stick with Git::bash?

[agross]

I have the same issue. As soon as I run Cygwin bash or zsh through the connector, ruby -e 'puts STDOUT.isatty' displays false.

The task is defined as follows:

"%ConEmuBaseDir%\conemu-cyg-64.exe" -cur_console:p /usr/bin/bash --login

Leaving out -cur_console:p makes no difference:

"%ConEmuBaseDir%\conemu-cyg-64.exe" /usr/bin/bash --login

[Maximus5]

@agross Where is your ruby located? I think it's not inside your cygwin folder (how did you install it?)

[agross]

@Maximus5 No, it's not, it's in C:\Ruby (from https://rubyinstaller.org/). It might be related to Ruby, as if test -t 0; then echo is a tty; fi prints is a tty in both cases (using Connector or not).

[Maximus5]

So, the same comment

The nature of connector is that you have posix terminal (pty) as result. That's the same as you run something in mintty or in real linux console. Native Windows applications shall reopen $CON handles to obtain Windows console API.

[akrieger]

Sorry to bump this, but I think the context on this thread is relevant to this.

I've been experimenting with pure git bash, git bash via conemu, git bash via conemu connector, msys2 bash via connector, and straight msys2 bash (all hosted in conemu).

What I've found is that the connector appears completely unnecessary for msys2 bash as of today. I get full ansi support with high performance by just setting my startup task to execute msys2 bash directly. In fact, stress testing the performance with by using eg. buck build -c ui.superconsole=ENABLED -c color.ui=always shows better performance (update fps) than via the connector.

Interestingly, test -t 0; then echo is a tty; else echo is not a tty; fi prints is a tty regardless of whether I'm using the connector or not. Maybe this is an enhancement of msys2?

Additionally, signals like ctrl-c don't seem to propagate correctly through the connector, but work fine when directly invoking bash.exe instead. I try to ctrl-c to kill the buck build, and I do get a shell prompt back, but some child process is still running and executing the build in the background and printing to the console. This does not happen with straight bash.exe.

Should we file issues for the connector performance/signals, or maybe just say it's not worth using the connector for modern msys2 bash.exe?

[Maximus5]

The purpose of connector is simple: get RAW ANSI sequences from cygwin/msys/msys2 shells. You can't use ANSI without connector to setup, for example, shell working directory notification

https://conemu.github.io/en/CygwinMsys.html#cygwin-connector

[akrieger]

I can cd within bash and the tab in ConEmu updates to the correct value, without using the connector.

[akrieger]

Startup task: set CHERE_INVOKING=1 & "C:\work\msys64\usr\bin\bash.exe" --login -i

PS1:

PS1='\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '

[Maximus5]

Tab updated because of console title change. Neither %f nor %d works in your configuration. Shift+Home selects full console line instead of typed command. Console restart moves you to home directory. I can continue.

[akrieger]

Ah, ok, I see. So it only seems to work. Thank you for explaining what I was observing.

Should I at least open a new issue for connector/conemu screen redraw performance, and ctrl-c propagation issue?

[Maximus5]

You may

[MaximusSeniorem]

Tab updated because of console title change. Neither %f nor %d works in your configuration. Shift+Home selects full console line instead of typed command. Console restart moves you to home directory. I can continue.

Hum... Sorry to bump this again, I'm not that used to git ticket/threads.. yet The issue regarding 256 color scheme lead me here and I didn't see any other related tickets.

If I may add two things: 1) cat "$ConEmuDir/ConEmu/Addons/AnsiColors256.ans" seems to 'activate' the full coloring without having to disable the scrolling... until your next clear though. But I might use that as a work around since scrolling is quite useful.

2) I'm bumping this ticket mainly because of the issues you mentioned @Maximus5. I don't know what are %f, %d, but I noticed that I have the two others issues within the default Task Bash::Msys2-64; before trying said tricks in the first point..

Should I raise a ticket or is this already somewhere else that I didn't find ? Is there a post/ticket somewhere that completes the list you began ?

---

edit: 1) Is quite unstable though... going in and out of vim (syntax-coloring?) seems to also do the trick That's quite peculiar...

mmmpf seems I might have to go back to 16 colors for now.