$SHELL is invalid in Vim when run via `git commit`

[benmoss]

Any vimscripts that use has("unix") or has("win32") etc will incorrectly detect that the Vim bundled with this project is not running Windows.

This code in particular for the Syntastic plugin is causing issues for me: https://github.com/scrooloose/syntastic/blob/50d0315835047c35a1f6f6edf214e612d6eae3dd/autoload/syntastic/util.vim#L11-L13

[dscho]

I guess that we should keep saying "yes" when has("unix") was called: our VIM is an MSys2 one, i.e. it knows about POSIX paths and uses POSIX functions emulated by the MSys2 runtime.

[benmoss]

I traced this down a bit. It seems that when vim is started by Git, as in EDITOR=vim git commit, doing :echo $SHELL reports C:/Program Files/Git/usr/bin/bash, instead of the normal /usr/bin/bash. Not sure what is unique about the way vim is launched for a commit, but will try to debug further.

As for whether has('unix') is accurate, I would say yeah it probably is, but has("win64") etc should also probably be true.

[dscho]

doing :echo $SHELL reports C:/Program Files/Git/usr/bin/bash, instead of the normal /usr/bin/bash.

This is most likely due to MSys2's runtime converting the SHELL variable from POSIX to Windows format before running the (non-MSys2) git.exe. Then, when git.exe calls (MSys2) vim.exe, the variable does not get converted back to POSIX format.

For the record: this issue has been mentioned before (BTW thank you for providing precise and correct title and description in this ticket, I really appreciate this).

I have a hunch that the best place to patch would be https://github.com/git-for-windows/msys2-runtime/blob/e87aaa7d59deb2f4e5bff9cb114a0c45d1ae1a5e/winsup/cygwin/environ.cc#L317-L333

To test this hypothesis, you might find https://github.com/git-for-windows/git/wiki/Building-msys2-runtime to be a useful resource.

[mhoran]

We added the following to environ.cc and recompiled:

diff --git a/winsup/cygwin/environ.cc b/winsup/cygwin/environ.cc
index 2ab6d28..3799cbf 100644
--- a/winsup/cygwin/environ.cc
+++ b/winsup/cygwin/environ.cc
@@ -324,6 +324,7 @@ static win_env conv_envvars[] =
   {
     {NL ("PATH="), NULL, NULL, env_PATH_to_posix, env_plist_to_win32, true},
     {NL ("HOME="), NULL, NULL, env_path_to_posix, env_path_to_win32, false},
+    {NL ("SHELL="), NULL, NULL, env_path_to_posix, env_path_to_win32, false},
     {NL ("LD_LIBRARY_PATH="), NULL, NULL,
             env_plist_to_posix, env_plist_to_win32, true},
     {NL ("TMPDIR="), NULL, NULL, env_path_to_posix, env_path_to_win32, false},

Unfortunately, the issue persists. To verify that we were indeed compiling and moving the correct library into place, we removed the conversion for TEMP and verified that it was not converted in Windows.

Perhaps there's something special about SHELL?

[dscho]

Perhaps there's something special about SHELL?

Oh wow. I guess it must be, but I cannot find any verbatim mention of the term SHELL in MSys2's runtime's source code...

[mhoran]

Here's an interesting discovery: from the SDK shell, git commit launches vim without error. This works without a modified msys-2.0.dll in place. Does this mean anything?

[dscho]

Does this mean anything?

Well, I was curious and replicated your findings. This is what I got when I typed :!echo $SHELL<Return> in Git for Windows vs Git for Windows SDK:

Cannot execute shell C:/Program Files/Git/usr/bin/bash

Press ENTER or type command to continue

in Git for Windows, and in the SDK:

C:/git-sdk-64/usr/bin/bash

Press ENTER or type command to continue

This leads me to believe that it happens to work if Git is installed into a path that does not contain spaces, and fails otherwise. To test this hypothesis, I called

SHELL=/c/PROGRA~1/Git/usr/bin/bash git commit

in Git for Windows and all of a sudden, :!echo $SHELL<Return> works:

C:/PROGRA~1/Git/usr/bin/bash

Press ENTER or type command to continue

This leads me more and more to the conclusion that vim is actually at fault, for treating SHELL as if it was a command-line, not a path to an executable (that can contain spaces without quoting).

[dscho]

And indeed, a simple test in a Linux VM proves my hypothesis: vim interprets SHELL as a command-line, not a single path: starting vim as

$ mkdir with\ spaces
$ ln -s $(which bash) with\ spaces/
$ SHELL=$(pwd)/with\ spaces/bash vi

and then executing :!echo $SHELL produces:

Cannot execute shell /home/me/with spaces/bash

Press ENTER or type command to continue

When substituting with\ spaces with without-spaces, it works.

[mhoran]

Great find! We've opened an issue with vim.

[dscho]

Better to provide a patch.

[mhoran]

In reading the vim documentation for help 'shell', it seems that this is expected behavior:

        If the name of the shell contains a space, you might need to enclose
        it in quotes.  Example:
                :set shell=\"c:\program\ files\unix\sh.exe\"\ -f

What I'm not sure of is whether $SHELL should be quoted, or if vim should be quoting $SHELL when setting the shell variable. Comments on the vim issue seem to lean towards current vim behavior (no quoting).

I tried to set my login shell to a shell containing spaces, but chsh rejected my attempts because the shell was not in /etc/shells. When adding the shell to /etc/shells, it was still rejected, no matter what quoting or escaping I tried. It seems not possible to set a shell on UNIX/Linux to a path containing spaces.

I'm not sure where this leaves us. It doesn't seem like a patch to vim would be well received, and I'm not certain escaping the $SHELL variable on Windows is the correct thing to do either.