CTRL -C event is closing the ConsoleZ window instead of returning to a prompt #262
Comments
|
There's something really weird going on in the new bash and other tools that come with git. I have that bash as a shell in my ConsoleZ, and the first time I tried to Ctrl-C a command in it, I don't remember what command, it returned me to the bash prompt, then immediately to the cmd.exe prompt. Which is really weird because there shouldn't -be- a cmd.exe running underneath it, but apparently there is. And then I pressed enter a couple of times, and discovered that my keyboard input was going to both a bash and cmd.exe that were running in the same window somehow. |
|
When I try a CTRL C from the hidden console at view console the issue does not occur. It will just stop the running process and return to a command prompt. When I try CTRL C from git bash directly, the issue does not occur. It too will just stop the running process and return to the command prompt. The issue only occurs from ConsoleZ and it will close the window (or tab if there are multiple tabs) and it will leave the bash.exe process running. I always have multiple bash.exe processes left running even after I have hit CTLR C on their ConsoleZ windows and ConsoleZ is no longer running: I'm not sure if this a problem with ConsoleZ or with the git bash that gets installed with Git for Windows. Sorry if I've posted to the wrong place. Diagnostic Report: |
|
I'm seeing now that this has already been reported: issue #230. There have been several related issues opened in the git-for-windows repo. There are some helpful comments here in pull request #205 in git-for-windows. |
|
But there is still no solution, right? I'm confused after reading so many duplicated, closed tickets. |
|
@mriehema, I am using the following settings and my CTRL-C is working. I haven't encountered any breaking functionality with this, however @dscho warns that there may be issues with this (git-for-windows/git#205 (comment)).
|
|
@Sheparzo Thanks! The settings of the Environment was missing in my setup. So CTRL-C is working now, but my aliases in .bashrc, .bash_profile are missing (located in $HOME). :( |
|
@mriehema that's because of the issues I commented on in the other thread: hacking the environment variables (i.e. trying to out-guess the compatibility redirector in As I stated elsewhere: the proper fix will be to find out what exactly is going wrong with |
|
@cbucher the pull request you made (git-for-windows/git#205) is closed without resolution due to apparent problems. Is there any more development on this issue that will actually let us use ConsoleZ with the latest Git/bash? |
@dlong500 Yes, it was closed because there was no indication that my concerns would be addressed. In particular, if I had merged that PR, my setup would have been broken. If you are interested in this issue, why don't you pick up the ball and open a new Pull Request? |
|
@dscho I certainly am interested in the issue. However, I don't have the expertise required to fix it myself (nor do I have the time to gain such knowledge). Wish I did. That shouldn't mean I can't ask if there is any progress being made considering the issue is a showstopper for anyone wanting to use ConsoleZ with the latest Git/bash versions. |
|
Does anyone know the latest version of git-for-windows that does not have this issue? Also, what is this |
|
@KrekkieD There is an easy workaround: configure a well coded shell (which doesn't terminate when receive CTRL-C) in ConsoleZ tab settings. Try: git-cmd.exe will terminate, but ConsoleZ monitors cmd.exe and cmd.exe will survive. |
|
Is there a |
|
An easy workaround: change your Console shell command to the following:
|
|
I wasn't using ConsoleZ, but Console2 and ran into this same problem. The problem was present with: But it was NOT present with: One of the suggestions above has a screenshot with this difference, but I wanted to provide clarifying feedback that there does appear to be a difference in behavior between bin\sh.exe and usr\bin\sh.exe. There does not seem to be any difference in behavior between the sh.exe in a folder and the bash.exe in a particular folder. Namely, bin\bash.exe behaves the same as bin\sh.exe, and usr\bin\bash.exe behaves the same as usr\bin\sh.exe Hopefully this is useful to someone. |
|
@jeremydyoung i wish there was a +1 button. That's useful. |
|
With |
|
@jeremydyoung This did the trick! Thanks 👍 |
|
|
|
tl;dr for people that are looking to just have a bash environment in Windows using Git for Windows then use the bash.exe version at I upgraded to the latest git for windows (2.7.1.2-64) and consolez and started to get this problem, and I found out a little more information to add to the comment by @jeremydyoung above
C:\Program Files\Git\bin\bash.exe C:\Program Files\Git\usr\bin\bash.exe Who knows what the actual uses for each are from the Git for Windows perspective, but clearly the two executables are different, have different ctrl+c handling, may have different compilation options and the environment variables also may add different eventualities into the mix, after all this is an environment created for Git for Windows. For people wanting a more pure bash + git on Windows I would say it's probably worth trying to just install MSYS2 by itself and use pacman (the Arch Linux package manager that MSYS2 uses) to install git. I'm pretty sure that will work but I've not tested. See general package management here: https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ For those happy to just use the bash in Git for Windows then use the MSYS2 version. If you want to load profiles properly in the same vein as when SSHing onto a remote server then pass the |
|
tl;dr You Can't Believe Most Of What You Read On The Internet (A. Lincoln)
This is flawed advice, as I pointed out earlier already.
This is incorrect. To sum it up: |
|
@dscho thanks for better explaining about the wrapper. It makes sense.
Of the above if you want to use ConsoleZ then you have to choose the lesser of two evils, of which the latter is better (IMO). Hopefully there's a fix soon for the redirector, more and more these days I wish I knew C. Might be time to bite the bullet. git-for-windows/git#205 has a lot more info for anyone interested. |
You forgot one, rather crucial, option, the one option I would have prefered:
All it would need would be a person dedicated to driving the fix. Whatever knowledge is missing, I can provide, but not the time nor the incentive.
No one was born with knowledge of C. Chances are that you were exposed to some language similar enough to C, such as Javascript, Ruby, etc. Besides, you only need to imitate the surrounding code. And you are totally allowed to ask questions! |
|
@dscho - I have some (dusty) C knowledge, and can probably take a look at this some time this week. Can you point me in the direction that you think would be a good place to start? Thanks. |
|
@BiggerNoise could you first try with Git for Windows v2.8.1? It might be fixed in the meantime... |
|
Yes, that appears to have done it. My C skills remain safely locked away. I am starting the shell with "C:\Program Files\Git\bin\bash.exe" and no arguments. |
I expect the CTRL -C event to kill the currently running process and return to a bash prompt. Instead the CTRL -C event is closing the whole window with the latest version of Git for Windows (git version 2.5.0.windows.1).
The text was updated successfully, but these errors were encountered: