Detect whether ConEmu/Console2/whatever is installed and offer to use that instead of mintty

[dscho]

From https://gist.github.com/shiftkey/add6975be2687d8731ae#comment-1431040 and https://gist.github.com/shiftkey/add6975be2687d8731ae#comment-1432148, it appears that @oysteinkrog and @jaccus figured out ways to run the Git Bash inside ConEmu.

However, it still requires manual setup by users which is not exactly the user experience I am striving for.

There is already support in the Git wrapper (which is used as git-bash.exe, for example) to configure (without recompiling) the command-line to be run after setting up the environment variables. If there is interest, I'll gladly describe the technical details.

However, for ConEmu/Console2/whatever support, I will need to know two things for each terminal emulator:

1. how to detect that it is installed on the user's machine (registry setting?)
2. what is the command-line that executes the terminal emulator with a bash --login -i running inside. In other words, the equivalent of

"usr\bin\mintty.exe -i /mingw64/share/git/git-for-windows.ico /usr/bin/bash --login -i"

[oysteinkrog]

Hmm, I don't really know how to do that with conemu, and the fact that conemu can be installed as portable (no registry, only local xml settings) makes that quite hard to do for some setups.
Are you sure that this is something that has to be 100% automated, what about just giving the user directions to the wiki, where the setup procedure is described?

[dscho]

@oysteinkrog That will be my last resort, but I am not ready to give up just yet 😜

Anyway, could you elaborate on the local xml settings? Are they stored in a file in the portable app, or in the home directory?

And... how would you call ConEmu from cmd so that it automatically starts bash.exe --login -i and closes the window after the Bash quits?

[oysteinkrog]

Ok I think this works:
ConEmu64.exe /cmd @mingw64.txt
Where mingw64.txt has:
set MSYSTEM=MINGW64 & c:\git-sdk-64\usr\bin\mintty /usr/bin/zsh --login
Running the command inline with /cmd does not work it seems.
https://code.google.com/p/conemu-maximus5/wiki/ConEmuArgs

I have my conemu xml settings in the same directory as the exe, but not really on purpose.

[oysteinkrog]

Also tested with just this in the task file:
set MSYSTEM=MINGW64 & c:\git-sdk-64\usr\bin\bash --login -i
Seems to work, but I'm not sure how well, I've always used mintty as a wrapper.
Edit: colors/fonts are messed up, not sure if it is just my settings though.

[dscho]

Just for fun, would you be willing to use a resource editor like ResEdit to edit the string resources of git-bash.exe and replace the line

"usr\\bin\\mintty.exe -i /mingw64/share/git/git-for-windows.ico /usr/bin/bash --login -i"

with

"C:\path\to\ConEmu64.exe" /cmd "/usr/bin/bash --login -i"

and then double-click it in the Explorer?

[oysteinkrog]

Ok did that, replaced with:
"D:\APPS\UTILS\ConEmu\ConEmu64.exe" /cmd "/usr/bin/bash --login -i"

When starting from explorer, conemu prints:

The system cannot find the path specified.


Current directory:
C:\Users\Øystein

Command to be executed:
"C:\Windows\system32\cmd.exe" /C "/usr/bin/bash --login -i"


ConEmuC: Root process was alive less than 10 sec, ExitCode=1.
Press Enter or Esc to close console...

[oysteinkrog]

When using this instead it works:

\"D:\\APPS\\UTILS\\ConEmu\\ConEmu64.exe\" /cmd @D:\\APPS\\UTILS\\ConEmu\\mingw64.txt

The contents of the file is the same as that of a task.
When launching my conemu this way it does not load the portable settings xml file I use (placed next to conemu exe).

[dscho]

So you need mintty to run inside ConEmu?

BTW I really would like to avoid an extra text file, it is cumbersome to keep around...

[oysteinkrog]

Well yes, I use conemu as quake-like console (drop down) with tabs (can have cmd etc as tabs).
It does seem like using bash/shell directly inside conemu works as well, but I don't really do that as the mintty setup works well.
The messed up colors is probably just a color profile issue in conemu (I use solarized shell colors).

[oysteinkrog]

I can't get conemu /cmd "bash.exe" to work though, only the file-based approach, tried lots of different versions, but I might just be missing something.

[jaccus]

I'm just wondering whether the use case you guys described is actually worth looking into.

I dare to assume that most ConEmu/Console2/whatever users are not limiting themselves to Git bash tasks (tab kinds). I myself, have always had at least Cmd, PowerShell and Bash (with Git) tasks configured and can start each of those in a new tab with some global ConEmu shortcut. Therefore, starting Git Bash in ConEmu via an external executable (such as git-bash.exe) does not bring much value in that case.

As for detecting whether 3rd party console tools are installed in the system - this is a struggle, since some users always go for stand-alone packages and so registry settings on Windows are not a viable option. Then, as long as you cannot get the feature working for majority, I wouldn't bother.

One thing I think could be useful and does not require much work, is a short section in README, which provides a short "how to use git-for-windows from 3rd party terminal tools" guide with samples.

[davux]

Agreeing 100% with your comment, jaccus.

ConEmu is the terminal, bash is the shell. The terminal runs the shell, not the other way around. What we could do is to work with ConEmu developer, Maximus5, to provide a task for us in ConEmu.

As others have said, set MSYSTEM=MINGW64 & C:\git-sdk-64\usr\bin\bash --login -i seems to be a working task. (I just have a problem with the terminal type: I have to run export TERM=cygwin if I want the terminal to be cleared when I type Ctrl+L.)

[dscho]

Therefore, starting Git Bash in ConEmu via an external executable (such as git-bash.exe) does not bring much value in that case.

Well, at the moment you hardcode MSYSTEM for it to work correctly. That means if we have to configure even more things via environment variables, and teach our git-bash.exe to do that, you will have to fix up your configuration manually and you will have to actually notice that something needs to be changed. If you would be able to use git-bash.exe instead, it would make things easier because only we would have to update the configuration and you would not have to bother with implementation details.

One thing I think could be useful and does not require much work, is a short section in README,

People do not read the README. Period. Just have a look at how many issues are reported in https://github.com/msysgit/msysgit/issues and https://github.com/msysgit/git/issues that would have been addressed in the release notes iff people bothered to read them...

The terminal runs the shell, not the other way around.

True. What I want to do is not let the usr\bin\bash.exe run your terminal, though. What I want is that git-bash.exe opens the Bash in the user's favorite terminal window.

What we could do is to work with ConEmu developer, Maximus5, to provide a task for us in ConEmu.

I get the distinct impression that there is an assumption going on that everybody understands what ConEmu means by "task". Obviously, I don't, though. Do I need to learn about this? If yes, would any of you gentle people be willing to summarise for somebody who is not inclined to become a user of ConEmu but still wants to support Git users who are infatuated with ConEmu?

As others have said, set MSYSTEM=MINGW64 & C:\git-sdk-64\usr\bin\bash --login -i seems to be a working task.

And as I have pointed out (this time, explicitly): this is prone to get stale. If you are happy to adjust your configuration manually everytime we decide to move things around (for example, the bash.exe moved from /bin/ to /usr/bin/ between Git for Windows 1.x and 2.x, as did /libexec/git-core/ to /mingw64/libexec/git-core/ (or /mingw32/libexec/git-core/ for 32-bit). These are adjustments outside of your control, and a big reason why we aim to keep a few things constant, such as the location in the start menu or /git-bash (although it was converted from a .bat to a .exe file). In my mind, it would make for a much better user experience if the installer offered as much convenience for the users and they would not have to read through documentation they might be bothered to find in the first place only to be forced to edit some text files themselves afterwards.