5

On my Windows machine, running gVim appears to tie up the git for windows shell, whereas if I run from the command prompt, this is not the case.

How might I be able to run gVim (or any other program, really) without tying up the shell and having to add an '&' to the end of each command?

Any help on this issue would be much appreciated.

Git Bash:

$ gvim hello.txt
[Terminal is now blocked]
[Hit ctrl+c or close gvim, terminal takes input]
$ 

Windows Command Prompt:

> gvim hello.txt
> [ Can still access cursor and execute commands]
3

The answer I've found that works most like it does on my Linux box is to set an alias in your .bashrc:

alias gvim='start gvim'

This is still not the most ideal fix, but it feels a little cleaner to me than creating a function. Also it does not print the process ID line (example: "[1] 6840") when you run it or when you close the external window.

This still has the problem from the function fix that it only works for things you create an alias for. So notepad for example still blocks your bash unless you create a start notepad alias. Based on this post at the MSDN blog it looks like Windows executables have a flag that tells the console whether or not it is a GUI application, but from what I can see, git bash does not differentiate based on that flag in the same way that cmd.exe does. If you could attach something to every command entered that would check the .exe for the GUI flag, and prepend start based on your result, then you'd be good to go.

| improve this answer | |
  • Why do you feel that aliases a cleaner than functions? They are practically the same thing, and functions are a lot more powerful and flexible. – G-Man Says 'Reinstate Monica' Jan 13 '15 at 22:25
  • 1
    Since the only goal here is to start Gvim in an independent process, throwing the start command on the front of it does just that and no more. When you make a function, now you're writing code that takes arguments and can do all these other things that you don't need to do. More powerful and flexible is great when that's what you need, but it's overkill when you just need to put the word start in front of your command. – Zurcher Jan 14 '15 at 20:07
  • For me, this starts a new cmd window in addition to a gvim instance. Any idea why? – Kyle Strand Oct 10 '17 at 21:56
  • Realized I never marked an accepted answer. I'm going to mark this one since for the reasons @Zurcher outlined in the comment. – funseiki Jun 3 at 18:57
2

The quickest (and possibly dirtiest) solution I've found to be able to use gvim in the way I'm used to was to modify the .bashrc file.

I added the following function to the end of it:

gvim()
{
    /path/to/gvim.exe "$@" &
}

The "$@" takes arguments passed in from the shell, and the & forces gvim to run in the background.

I'd like to not mark this answer as accepted, as there might be a better solution (e.g. I screwed up my msys/vim settings somewhere).

| improve this answer | |
  • I found that roughly 90% of the time, this works perfectly. About 10% of the time, the focus stays on the git bash Window, causing me to accidentally type a bunch of vim keystrokes into the bash shell. An older version of git did not have this issue. Is anyone else affected? – Jeff Irwin Sep 27 '17 at 19:30
0

You can run any program in the background from bash by using &:

gvim &

Gvim is different from most programs and normally puts itself in the background without the need for the &. To run it in the foreground, you normally have to start it with the -f option. I don't know why gvim is not behaving that way from bash on Windows.

| improve this answer | |
  • 1
    Right, I was hoping I could avoid the '&' since it works as intended on a regular command prompt :/ – funseiki Mar 21 '13 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.