git help <command> dosen't work in the latest release

[shine4444]

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

** git version 2.20.1.windows.1 **

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

**64-bit**

Details

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

** git help <command> **

• What did you expect to occur after running these commands?

**open the local help html file **

• What actually happened instead?

**warning :/usr/bin/start: line 8: cmd: command not found **

[dscho]

Why did you delete most of the questions? Now I have to ask, tediously, all the information that is relevant to your problem.

So first things first: it works here.

Next: how come that cmd.exe is not in your PATH? Do you use Git Bash, Git CMD, CMD, PowerShell, watever?

(These are questions I should not need to spend time asking, we have that issue reporting template for a good reason: to help you write a complete bug report rather than an incomplete one.)

Please do be mindful of others' time, especially of those persons who you ask for help.

[bruno-medeiros]

I'm experiencing either same underlying issue, or a very related one. When I invoked any help, the Windows Command Prompt is started in the shell where git was invoked:

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

Git-2.20.1-64-bit

$ git --version --build-options

git version 2.20.1.windows.1
cpu: x86_64 
built from commit: 7c9fbc07db0e2939b36095df45864b8cda19b64f 
sizeof-long: 4 
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
  Windows 10 Pro 64bit

$ cmd.exe /c ver 
Microsoft Windows [Version 10.0.17134.523]

• What options did you set as part of the installation? Or did you choose the
  defaults?

$ cat /c/Program\ Files/Git/etc/install-options.txt
Editor Option: Notepad++
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
--

• Any other interesting things about your environment that might be related
  to the issue you're seeing?
  Nope

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Git Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git help push
or
git push --help

• What did you expect to occur after running these commands?

Help is shown

• What actually happened instead?

Windows Command Prompt opens

[dscho]

@bruno-medeiros that does not happen here. Can you run this with GIT_TRACE=1?

[bruno-medeiros]

Oops, a minor correction, git help works fine! It's git help <command> (or git <command> --help) that causes the problem. For example:

bruno@Forge-10 MINGW64 ~
$ GIT_TRACE=1 git help push
17:49:13.978263 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
17:49:13.978263 git.c:418               trace: built-in: git help push
17:49:13.978263 exec-cmd.c:333          trace: exec: git web--browse -c help.browser 'C:/Program Files/Git/mingw64/share/doc/git-doc/git-push.html'
17:49:13.990395 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:13.990395 git.c:675               trace: exec: git-web--browse -c help.browser 'C:/Program Files/Git/mingw64/share/doc/git-doc/git-push.html'
17:49:13.990395 run-command.c:643       trace: run_command: git-web--browse -c help.browser 'C:/Program Files/Git/mingw64/share/doc/git-doc/git-push.html'
17:49:14.061100 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:14.202629 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:14.202629 git.c:675               trace: exec: git-sh-i18n--envsubst --variables 'usage: $dashless $USAGE'
17:49:14.202629 run-command.c:643       trace: run_command: git-sh-i18n--envsubst --variables 'usage: $dashless $USAGE'
17:49:14.218256 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:14.271746 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:14.271746 git.c:675               trace: exec: git-sh-i18n--envsubst 'usage: $dashless $USAGE'
17:49:14.271746 run-command.c:643       trace: run_command: git-sh-i18n--envsubst 'usage: $dashless $USAGE'
17:49:14.287371 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:14.387649 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:14.387649 git.c:418               trace: built-in: git config help.browser
17:49:14.418901 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:14.418901 git.c:418               trace: built-in: git config web.browser
17:49:14.472321 exec-cmd.c:236          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:49:14.472321 git.c:418               trace: built-in: git config browser.start.path
Microsoft Windows [Version 10.0.17134.523]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Users\bruno>

[dscho]

Sounds like your git-web--browse runs start as intended but that you either have configured browser.start.path to something funny, or you have a funny start in your PATH.

[bruno-medeiros]

Hum, I haven't modified browser.start.path (that I know of), and the start on PATH looks like is the one from Git:

Is that cmd //c correct? Should it not be cmd /c (or some other related change) ?
I've checked in process explorer that the last process created when invoking git help push is

C:\WINDOWS\system32\cmd.exe //c start "\"web-browse\"" "C:/Program Files/Git/mingw64/share/doc/git-doc/git-push.html"

If I change //c to /c, it works, browser starts normally. I wonder why the /c Unix to Windows path conversion is not happening though (given this https://github.com/msys2/msys2/wiki/Porting#filesystem-namespaces )

[bruno-medeiros]

Oh wait, I found it. I had MSYS2_ARG_CONV_EXCL set to *. This made /c stay as /c, and //c stay as //c, hence why cmd /c start was working on my setup, but not the default.
This is a bit annoying as I'm not sure of a clean way to work around this. I still want `MSYS2_ARG_CONV_EXCL='*' because of Docker, otherwise it interferes quite a bit with it. Hum, okay, on second thought, maybe I should alias the docker command itself to remove the conversion only for that command.

[dscho]

Why not patch start to deal with this by unsetting MSYS2_ARG_CONV_EXCL? That should work around this, no?

[bruno-medeiros]

That could work too, although for now I'm preferring to unset MSYS2_ARG_CONV_EXCL globally, and just set it for specific commands (like Docker), with an alias. As far as I'm concerned this issue is resolved. I dunno about the problem of the first poster.
(If anyone is curious, now I'm stuck on a different issue: msys2/MSYS2-packages#411 related to winpty always doing some path conversion, totally ignoring MSYS2_ARG_CONV_EXCL)

[rybak]

I've stumbled upon the same issue with /usr/bin/start complaining about missing cmd after upgrading to 2.20.1. I've checked two previous versions. Same error for 2.19.1. Works fine on Git for Windows 2.18.0.

@dscho, to answer your question:

Next: how come that cmd.exe is not in your PATH?

At least in my setup in 2.20.1, System32 reaches PATH in following form:

%SystemRoot%/system32:%SystemRoot%:%SystemRoot%/System32/Wbem:%SYSTEMROOT%/System32/WindowsPowerShell/v1.0

It looks like Windows-style environment variables are not recognized by Git Bash in PATH.

In 2.18.0, the same part of the PATH looks like this:

:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0:

[dscho]

That is funny, indeed.

Could you wiggle this a little further down? There were a couple of versions between 2.18.0 and 2.20.1; you should be able to use the Portable Gits to perform those tests, avoiding to override your system's Git for Windows.

Once you pinned it down to a release, compare the etc/package-versions.txt contained therein. My guess is that the difference is in msys2-runtime, more specifically in the usr/bin/msys-2.0.dll file. If my hunch is correct, copying that file from a working Portable Git to a non-working one will make the latter work.

[rybak]

Could not reproduce the issue in portable version. Tried reproducing with just the installed version. Could not get conclusive results (see table below), so I started comparing "portable" and "installed" on the same versions.

During testing I found a weird dependency between launches of different Git Bash exe files. Steps:

1. Install 2.20.1.
2. Check git help commit in installed version -- does not work with cmd: command not found error.
3. Launch Git Bash 2.20.1 in portable version.
4. git help commit works in portable version.
5. Check the installed version again: and it magically started working.

If on a just installed version the help command did not work, launching the portable version once was enough to "fix" the installed version.

Inconclusive results: one attempt for portable versions, and three attempts for installed:

version	portable	installed
2.18.0.windows.1	?	+?-
2.19.0-rc0.windows.1	+	??-
2.19.0-rc0.windows.2		??-
2.19.0-rc1.windows.1	+	??-
2.19.0-rc2.windows.1	+
2.19.0	+
2.19.1	+	-??
2.20.0-rc2.windows.1		?-?
2.20.0		?-?
2.20.1.windows.1		-+-

Plus -- git help commit worked.
Minus -- cmd: command not found
Question mark -- did not test that version on that attempt.

After the correlation between launching portable version and successful tests have been confirmed, the plus on second attempt for version 2.20.1.windows.1 is probably caused by that.

[dscho]

And the environment you have in a plain cmd still shows the percent characters in PATH?

[rybak]

No:

C:\Users\rybak>echo %PATH%
[snip]
;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;
[snip]

[dscho]

@rybak how about the Environment Variables in the System Properties (in your Control Panel)?

[rybak]

All with percent characters:

[dscho]

Same for me.

But. But, but, but... OMG I think I figured out something! My testing was in Git for Windows' SDK, which has a /usr/bin/cmd... And Git for Windows does not! D'oh!

The contents of /usr/bin/cmd are:

#!/usr/bin/env bash
# Copyright (C) 2014, Alexey Pavlov
#   mailto:alexpux@gmail.com
# This file is part of Minimal SYStem version 2.
#   https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
# File: cmd

"$COMSPEC" "$@"

And the contents of /usr/bin/start are:

#!/usr/bin/env bash
# Copyright (C) 2014, Alexey Pavlov
#   mailto:alexpux@gmail.com
# This file is part of Minimal SYStem version 2.
#   https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/
# File: start

cmd //c start "${@//&/^&}"

So it wants to start cmd, and obviously it wants to find /usr/bin/cmd, and if it does not, it tries to find it elsewhere in the PATH. If it cannot find it, then you get this dreaded

/usr/bin/start: line 8: cmd: command not found

The obvious best fix is to avoid that indirection to the non-existing /usr/bin/cmd and use "$COMSPEC" directly.

So what I will do is to edit the /usr/bin/start file in the post-install script of the git-extra package (where we do all kinds of hacks of this sort), replacing the cmd by "$COMSPEC".

If y'all could verify that this fixes the issue on your end, too, that would be lovely.

[rybak]

What about the underlying issue of %PATH% sometimes incorrectly translating into $PATH?

[dscho]

@rybak this is really a conundrum I was not quite able to solve: at first, in a fresh VM, I could reproduce the issue! And then I changed the /usr/bin/start to verify that it fixes things for me. Then I changed it back to investigate further but the environment no longer had any percents in them!

So my take on it is that something (most likely, the invocation of even a single CMD) will expand those environment variables globally. However, this seems to be 1) very finicky/time-consuming to track down and 2) not really relevant, as soon as we use $COMSPEC in start, so I decided to spend my time elsewhere (I spent 6h on the bug tracker today, which is no fun at all...).

[rybak]

Fair enough.

…

On Wed, 27 Feb 2019, 15:21 Johannes Schindelin, ***@***.***> wrote: @rybak <https://github.com/rybak> this is really a conundrum I was not quite able to solve: at first, in a fresh VM, I could reproduce the issue! And then I changed the /usr/bin/start to verify that it fixes things for me. Then I changed it back to investigate further but the environment no longer had any percents in them! So my take on it is that *something* (most likely, the invocation of even a single CMD) will expand those environment variables *globally*. However, this seems to be 1) very finicky/time-consuming to track down and 2) not really relevant, as soon as we use $COMSPEC in start, so I decided to spend my time elsewhere (I spent 6h on the bug tracker today, which is no fun at all...). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2014 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAmFyHAkH2sfj7Oa43nwYP5KaBRnO9mMks5vRpR-gaJpZM4Z3w6e> .

[dscho]

@rybak of course, if you find it in yourself to continue the hunt, I think it would be interesting to get to the bottom of this. As I said, my hunch was that invoking even one CMD would resolve the issue for all processes. If you find that this is true on your system, too, it would explain a lot.