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.

[davux]

there is an assumption going on that everybody understands what ConEmu means by "task". Obviously, I don't, though.

You're right. Let me try to explain in a few words. ConEmu is a terminal, i.e. only a container for whatever you might want to run inside it. Typically a shell like cmd.exe, bash.exe, or powershell. One nice thing is that it has tabs and splitting (à la screen/tmux, but handled at the GUI level), and that you can have different shells running in each of those "slots". A task is a type of shell you want available. Each has a name and the actual command to run. For example one task will be called e.g. "Command prompt" and the command would be "cmd.exe", another one would be for git-bash, maybe another one for irssi, etc. Then whenever you create a new tab or split an existing tab, you decide what task you want to run inside that new "slot". I hope that makes it clearer.

Do I need to learn about this?

You don't really need to, since the beauty of it all is that all those components should be independent from each other. However, since you're into shells and command line, I highly recommend you to try ConEmu. It will help your understanding a lot and maybe even give you nice integration ideas! Heck, you might even like it for yourself. :)

this is prone to get stale.

Very fair point. As you pointed out, as a Windows GUI user, I want to be able to click on some icon and get a terminal window with a shell inside, no questions asked. Similarly, as a ConEmu user, I want the same but without the terminal window. In other words, I want to be able to add a stable bat/exe command as a task that would run git-bash "alone" (no GUI), with all the environment being taken care of.

[dscho]

So how do you provide those "tasks"? Would it make sense to add a "Browse" button that lets the user specify the "ConEmu" location to add that task automatically?

[Maximus5]

BTW. When user "installs" ConEmu and runs it first time, ConEmu tries to find known 'shells' and create tasks. So user can choose what he wants to run on startup.

And any task can be easily started when it is necessary.

[tkelman]

@jan-hudec #74 (comment)

I mentioned ConEmu to suggest that if the problem with cmd.exe is that it is crap, it would be better solved by pointing people to ConEmu then by using mintty, which has it's own problems.

Not necessarily. ConEmu can introduce huge performance problems in process spawning (git-for-windows/msys2-runtime#6 (comment)), so would need to be benchmarked carefully before recommending it as default.

[tkelman]

@jan-hudec

It would be nice if Git for Windows could disable conemu hooks when running commands implemented externally (like git-svn) or that use many helpers (like git-fetch). I think they could be disabled for everything, possibly except interactive rebase which may run user-specified commands.

There is a conemu PKGBUILD here https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-conemu-git with a default xml configuration file that could be adjusted as desired.

[Maximus5]

@tkelman

ConEmu can introduce huge performance problems in process spawning

cmder is bundled with old ConEmu build so it is not a sign. And neither of linked issues are linked to ConEmu project.
I believe, current ConEmu builds have no performance problems with cygwin spawning.
And it's strongly not recommended to disable ConEmuHk to avoid crashes and other problems.

It would be nice if Git for Windows could disable conemu hooks when running commands implemented externally (like git-svn) or that use many helpers (like git-fetch). I think they could be disabled for everything, possibly except interactive rebase which may run user-specified commands.

It is already possible but as I've said before is strongly not recommended.

There is a conemu PKGBUILD here

Do not see any sense in this PKGBUILD. I believe official version must be always preferred. It is working, supported and can be adjasted with ConEmu.xml by deployers.

[tkelman]

Do not see any sense in this PKGBUILD.

Simple, to fit into Git for Windows' build system.

[Maximus5]

There are not only PKGBUILD file, but also two patches. And more, as far as I can see, this git suggest to have either 32-bit or 64-bit binaries. That's absolutely wrong. You have to have both bitness on 64-bis OS'es. And it is invalid to disable ConEmu checks.
Anyway. Much more preferable way is to open an issue or pull request at ConEmu project instead of creating un-linked and un-forked git-s.

[jan-hudec]

It would be nice if Git for Windows could disable conemu hooks when running commands implemented externally (like git-svn) or that use many helpers (like git-fetch). I think they could be disabled for everything, possibly except interactive rebase which may run user-specified commands.

[Maximus5]

@jan-hudec
Have you not read my previous comments? 1. It's strongly not recommended. 2. But it's already possible. Anyway I don't see the sense in hooks disabling.

[jan-hudec]

It would be nice if Git for Windows could disable conemu hooks when running commands implemented externally (like git-svn) or that use many helpers (like git-fetch). I think they could be disabled for everything, possibly except interactive rebase which may run user-specified commands.
It is already possible but as I've said before is strongly not recommended.

These are MSys programs. They are unlikely to hit those problems and if they do, appropriate workaround can be made in msys; most of the problems are not really conemu-specific anyway.

I am aware, that it is possible on the ConEmu side. I am suggesting to make git disable it for itself only while it remains enabled for any other command the user executes.

I believe, current ConEmu builds have no performance problems with cygwin spawning.

Does it apply to msys spawning too?

Have you not read my previous comments?

I was just moving the comment from the wrong place to the place where I should have made it in the first place. So I could not have seen the comments that were made in response to that comment.

[dscho]

@Maximus5 if we are to bundle ConEmu with Git for Windows, it has to be

• small enough (mintty only adds a ~170kB penalty)
• be bundled as a MinGW package to be installed (and updated) via Pacman
• supported well enough (i.e. no user should be forced to manually adjust some text files e.g. to tweak the performance characteristics

So: how large is it? Can you fix the PKGBUILD to do what you deem is appropriate? What hacks, and how many of them, would we need to litter Git's source code with, to get decent performance out of running Git in ConEmu? Would these hacks be so invasive that they actually affect other terminal emulators?

[Maximus5]

Does it apply to msys spawning too?

I believe msys has same spawning mechanism. You can check the speed yourself if you doubt in...

[elyscape]

Hooray! Sorry I wasn't of more help.

[Maximus5]

What have I to run in ConEmu (default Git's Task content) to run git bash?

git-bash.exe --command=usr\\bin\\bash.exe --login -i

[landstander668]

@Maximus5 Here's the ConEmu task command I'm using, based upon the info from here.

"%ProgramFiles%\Git\git-bash.exe" --needs-console --no-hide --minimal-search-path --command=usr\\bin\\bash.exe --login -i -new_console:t:"git-bash.exe":C:"%ProgramFiles%\Git\mingw64\share\git\git-for-windows.ico"

It seems to work well, except for an extra tab being created.

[dscho]

@landstander668 what if you skip the --needs-console option, or replace it by --no-needs-console?

Or is this a ConEmu issue, @Maximus5 ?

[Maximus5]

Two tabs is a ConEmu issue I think.

[landstander668]

@dscho I get the exact same behaviour when using --no-needs-console (or skipping the option entirely).

[bviktor]

So after all, what's the proper way to invoke Git2 from ConsoleZ? My biggest problem is that while Git1 used a single binary folder, Git2 uses at least 2 so not even basic commands will work.

[dscho]

@bviktor the recommended way to access Git for Windows is, and has been, to use /cmd/git.exe. If that fails, it is a bug and we have to fix it, together.

[Maximus5]

I think @bviktor want to have bash prompt where git and msys binaries are available (via PATH).
Unlike ConEmu, ConsoleZ don't support GUI binaries to be running in tabs. So user have to start git-cmd.exe to run initialized git prompt. However it starts cmd.exe prompt.
The following will start bash prompt in Console:

c:\git\git-cmd.exe --command=c:\git\usr\bin\bash.exe -l -i

[Maximus5]

Found (and fixed) two-tabs problem within ConEmu. The problem was in CREATE_NEW_CONSOLE flag passed in CreateProcess. It is a spare flag actually because it's implied when console app is starting from GUI app.
Not a problem. Will be fixed in the next ConEmu build.

[dscho]

The following will start bash prompt in Console:

c:\git\git-cmd.exe c:\git\usr\bin\bash.exe -l -I

The minor problem is that user have to type exit twice to close the tab. That's because bash is started via /K switch. May be there is a better way?

Yep, I think you want to prefix the first argument with a --command=, i.e. --command=c:\git\usr\bin\bash.exe instead of c:\git\usr\bin\bash.exe.

[Maximus5]

Well, --command=... is working. Strange, I was sure had tried it without any luck.

But now... May be this way (with git-cmd.exe) is better for ConEmu tasks too? Are there any benefits of using git-bash.exe instead?

[bviktor]

Yup, I want a shell, not just the git binary itself.

• usr\bin\bash.exe --login -i: this is what I had to use with Git1 (without the usr\ part). Works, but git commands are unavailable
• cmd\git.exe: it's just the git binary, not the shell
• git-cmd.exe: works, but misses other stuff like grep
• git-cmd.exe --command=usr\bin\bash.exe -l -i: seems to work perfectly! Opens a new shell on a new tab and all the shell and git commands are available.

Am I OK if I stick to this last one or will this change after your fix is in place, Maximus?

[dscho]

Well, --command=... is working. Strange, I was sure had tried it without any luck.

It is a pretty new feature, IIRC it only entered Git for Windows with version 2.4.2.

May be this way (with git-cmd.exe) is better for ConEmu tasks too? Are there any benefits of using git-bash.exe instead?

When overriding the command to be called, the only difference between git-cmd.exe and git-bash.exe is that the former is a GUI program while the latter is a console program. So: yes, it would be appropriate for ConEmu to use git-cmd.exe.

[Maximus5]

@dscho But I can't find way to start bash (via git-cmd.exe or git-bash.exe) in the specified folder instead of user profile. How to implement "git bash here" feature?

[bviktor]

Guys, one quite major issue I've hit with git-cmd.exe --command=usr\bin\bash.exe -l -i is that if I press Ctrl+C, it closes the Console tab altogether (if it's the only tab, closes Console as well). In fact, it closes the Console tab even if a script is running.

[Maximus5]

@bviktor This is Console/ConsoleZ problem. Report it to its author. Neither standard windows console (started from Win+R) nor ConEmu are closing this tab on Ctrl+C.

[bviktor]

Uh, this only happens with this new Git2 Bash, Git1 bash, CMD, PowerShell etc are working fine and don't close upon Ctrl+C.

[Maximus5]

Console must not make user experience worse. It anything is working in standard console, the same must be working in the Console.

[bviktor]

Start git-cmd.exe --command=usr\bin\bash.exe -l -i from CMD, it'll also behave really weird. One example is press Ctrl+C twice and then it prints More ? messages upon every keypress. I definitely don't consider this normal :)

[dscho]

I can't find way to start bash (via git-cmd.exe or git-bash.exe) in the specified folder instead of user profile. How to implement "git bash here" feature

@Maximus5 you can use the --no-cd option, or the --cd=<directory> option as used by Git Bash Here.

[dscho]

For the record, Git Bash recently learned the --cd-to-home option and no longer switches working directory by default.