Git Bash 2.24 hard breaking change: Git Bash windows command agument no more work and unwanted escaping.

[Yivan]

Hello,

A pretty hard bug is making many problems with some .sh script runned with Git Bash (Git-2.24.1.2-64-bit.exe).
If you try to run on 2.24: cmd.exe /C dir, it will open the CMD prompt without executing the command... !
Before it worked ok.

It works with cmd.exe //C dir, but runned command are auto-escaped where it is not needed.
Running: cmd.exe //C 'ftype sh_auto_file="C:\Program Files\Git\git-bash.exe" "%1"'
return sh_auto_file=\"C:\Program Files\Git\git-bash.exe\" \"%1\" (and so the file association don't work by the way...)
As for consequence a simple check in one of our .sh script no more works:

if [ "$(cmd.exe /C 'ftype sh_auto_file')" != 'sh_auto_file="C:\Program Files\Git\git-bash.exe" "%1"' ]; then
    echo "Attach Bash to .sh files by running cmd.exe command 'ftype sh_auto_file=\"C:\Program Files\Git\git-bash.exe\" \"%1\"'..."
    cmd.exe /C 'ftype sh_auto_file="C:\Program Files\Git\git-bash.exe" "%1"'
    echo "Ok."
fi

This is just an exemple, but this is really a problem for bash script calling windows utilities.
For now we will patch those call by proxifing them to powershell: powershell.exe -Command 'cmd.exe /C ....', it works ok.

But it is a real breaking change here made in Git Bash.
Is it a bug or wanted ? It is documented somewhere ?

Thanks a lot.

[Yivan]

For information I just downgraded to https://github.com/git-for-windows/git/releases/download/v2.23.0.windows.1/Git-2.23.0-64-bit.exe, and cmd.exe /C dir work well like before.

[dscho]

Hmm. This was supposed to work only with //c before, see the Known Issues:

• If you specify command-line options starting with a slash, POSIX-to-Windows path conversion will kick in converting e.g. "/usr/bin/bash.exe" to "C:\Program Files\Git\usr\bin\bash.exe". When that is not desired -- e.g. "--upload-pack=/opt/git/bin/git-upload-pack" or "-L/regex/" -- you need to set the environment variable MSYS_NO_PATHCONV temporarily, like so:

MSYS_NO_PATHCONV=1 git blame -L/pathconv/ msys2_path_conv.cc

Alternatively, you can double the first slash to avoid POSIX-to-Windows path conversion, e.g. "//usr/bin/bash.exe".

[Yivan]

Thanks for your fast return on this. I was aware of this flags.
But here there is a breaking change.

To be more precise, before 2.24:

• cmd.exe /C dir: work
• cmd /C dir: do not work
  Starting from 2.24 both don't work.

Before 2.24, calling commands with ".exe" was a good way to work because using .exe commands are pure windows so they must not have this automatic path conversion (many windows commands use the slash as parameter option).
So there has been really a change here which will break user scripts... If it is intentional, I think it should really be mentionned on top of the update release note as breaking change.

In any case, the code handling this should be reviewed to know why it has changed... and choose if we must come back to this new behavious or the old one.

I use the following versions for my test: Git-2.23.0-64-bit.exe and Git-2.24.1.2-64-bit.exe.

Thanks.

[dscho]

Git-2.23.0-64-bit.exe and Git-2.24.1.2-64-bit.exe.

Could you try again, but this time with the portable versions so that you can copy individual files from the latter to the former until it breaks, to pinpoint what component introduced the change? My hunch is that copying usr\bin\msys-2.0.dll to v2.23.0 will cause the new behavior.

[Yivan]

I just tried and like you guess it I confirm you are right. Changing the dll usr\bin\msys-2.0.dll like suggested make the 2.23 having the same problem than 2.24.

So the changes has been introduced in the usr\bin\msys-2.0.dll files of 2.24.

2.23: https://github.com/git-for-windows/git/releases/download/v2.23.0.windows.1/PortableGit-2.23.0-64-bit.7z.exe
2.24: https://github.com/git-for-windows/git/releases/download/v2.24.1.windows.2/PortableGit-2.24.1.2-64-bit.7z.exe

[dscho]

The difference can be seen in https://github.com/git-for-windows/build-extra/blob/master/versions/package-versions-2.23.0.txt#L107 vs https://github.com/git-for-windows/build-extra/blob/master/versions/package-versions-2.24.1.2.txt#L107: 3.0.7-3 vs 3.0.7-4

Looking at the commit history at https://github.com/git-for-windows/MSYS2-packages/commits/master/msys2-runtime, it seems that the difference between those two versions is contained completely within git-for-windows/MSYS2-packages@0bb0ec9#diff-8403b7464bfa043c51ef402beb7ac79b.

I cannot actually spot anything that would be responsible for the described behavior.

[Yivan]

Thanks for investiging it.
But sadly i cannot be of any help here as i am not able to read the code source of mysys.

There must be necessary a change somewhere, as the bug I mention is easily reproductible by just using the two git portable version on Windows.
Maybe this issue should be escalated to other experts of the git code source or msys ?

Thanks.

[dscho]

Closing stale ticket.