Associate with .sh files no longer works properly

[b9chris]

We've updated from msysgit/Git for Windows 32-bit to 64-bit on 3 machines now. We're late to switch so 2.5.2.2 is our first 64-bit version. Beforehand we had the .sh file associate working properly - double-click a .sh file, runs in Git Bash.

Now, there is a .sh association in the Registry, but what it fires off fails. Double-clicking a .sh file, you simply see a command prompt window flash. Nothing more occurs and the script does not run.

The .sh extension points to the sh_auto_file file type in HKEY_CLASSES_ROOT. That then holds the command,

"(msysgit)\git-bash.exe" --no-cd "%L" %*

Where (msysgit) is the Msysgit install path. It would seem there's something wrong with this command.

We can however run these same .sh scripts by typing them out - for example open Git Bash from the context menu and type ./scriptname.sh - runs fine.

Because we're late to switch it isn't clear when exactly this regression occurred.

[dscho]

The .sh extension points to the sh_auto_file file type in HKEY_CLASSES_ROOT. That then holds the command,

"\git-bash.exe" --no-cd "%L" %*

A little more precision would not hurt: HKEY_CLASSES_ROOT\sh_auto_file\shell\open\command is the key and the (Default) value should point to the complete path and the arguments, i.e. "C:\Program Files\Git\git-bash.exe" --no-cd "%L" %*.

And that is indeed what it does here, after a regular installation.

And that is indeed what the installer is told to do.

So feel free to rebuild the installer, possibly after fiddling with the install.iss.in file, to find out what the heck is going on.

[b9chris]

Yes, the installer did indeed place that command there for us as well. The problem is the command itself doesn't work - it results in that brief flash of a command window. So it's not the installer (and rebuilding the installer wouldn't help), so much as the command being added here.

It does appear this command has changed over time, so it would seem one of these changes resulted in this regression; for example when it was originally introduced it used:

"(msysgit)\bin\sh.exe" "--login" "%1" %*

And in fact if I replace the command the Installer placed here with the above, the .sh association works.

[dscho]

Yes, the installer did indeed place that command there for us as well.

But you reported that it places "\git-bash.exe" ... there, not "C:\Program Files\Git\git-bash.exe" ...! So what is it, does the installer place the same command there as for me or not?

[b9chris]

Neither, on some machines we use a custom install path. Wherever we installed git is reflected in the path in the command. Take another look at my comment above - I edited it to clarify this.

The install path isn't the issue - the command is the problem. It's pointing to git-bash.exe in the right location, but the way it's calling git-bash.exe is failing. Rolling it back to the old command, that calls bin\sh.exe, fixes it, as I mention above.

[dscho]

I edited it to clarify this.

Why not clarify in a new comment? That way I can follow you easier.

The install path isn't the issue - the command is the problem

Then you did a good job leading me astray from the issue by putting something different than the verbatim value in your initial comment. Not so nice.

Where (msysgit) is the Msysgit install path

And this is positively wrong. There is no Msysgit, and not even an msysGit (the latter was the correct spelling). The project called msysGit was retired.

In any case, I re-tested the .sh file association with a file containing these commands:

echo "Test" $1

(cd / && pwd -W)

read x

then double-clicked that file in the Windows Explorer and it does exactly what I think it should do: open a window, print a line reading "Test", printing another line corresponding to the installation path and then waiting for my input. When I hit the Return key, the script exits and the window closes.

Our guide lines indicate pretty clearly that complete examples are preferred to incomplete ones. May I suggest to provide that? Maybe a complete, minimal Shell script, together with a description that says what you expected to happen and what happened instead? By now we spent so much time hashing things out, and we are still not done yet, that it is unfortunately so late that my answer will have to wait until tomorrow.

[b9chris]

Sounds like maybe you were just reading the first version of the comment in email. You focused in on the path and that lead you astray. So, path: irrelevant. I don't think the name of this project matters much as it's also irrelevant, but as a reminder this code is in fact a fork of msysgit.

"git-for-windows/git
forked from msysgit/git"

We have 3 machines with this same issue so while your 1 machine has it working, I think you've still got a problem on your hands here.

The idea that the scripts are the problem doesn't fit because as mentioned 1) The scripts work if you call them from Git Bash 2) They work if we roll back the command to the old format.

For now we've resolved this across these machines by manually replacing the Registry command. When we have to attack it again on a 4th machine, I'll include a nonsense script for testing. But I suspect you'll have other users with this same issue in the meantime.

[nalla]

My HKEY_CLASSES_ROOT\sh_auto_file\shell\open\command contains "C:\Program Files\Git\git-bash.exe" --no-cd "%L" %* after a fresh install - and everything is working as intended.

The git-bash call forwards the double click into a /usr/bin/bash --login -i C:\Users\dev\test.sh call.

[dscho]

Sounds like maybe you were just reading the first version of the comment in email [...]

Do you want to solve your problems or do you want to turn this into a mud fight?

We have 3 machines with this same issue

So what is the issue? Instead of rambling on and on and confusing me even more, why don't you just come up with that simple example. Just like I did. My example works. I am still waiting for some example that demonstrates that it does, in fact, not work, as the title of this ticket claims.

Seriously, if you really want to solve your problem, let's focus on that problem. Like, really focus on it.

So: MCVE, please. Or close the ticket if you are no longer interested in solving this problem.

[Lunatrius]

I can confirm the issue. Using the following test.sh file:

#!/usr/bin/env bash
echo "Test" $1
(cd / && pwd -W)
read x

I get a console window popping up (and closing almost immediately) saying:

The filename, directory name, or volume label syntax is incorrect.

Registry entry:

[HKEY_CLASSES_ROOT\sh_auto_file\shell\open\command]
@="\"C:\\Development\\Git\\git-bash.exe\" --no-cd \"%L\" %*"

Replacing git-bash.exe with a simple batch script printing %* yields the following:

--no-cd "C:\Users\Lunatrius\Desktop\test.sh"

[dscho]

@Lunatrius thanks for bringing some sanity back into this conversation.

However, when I try the same thing as you, it does work correctly. FWIW I saved the test.sh file onto the Desktop and then ran explorer . in the Git Bash after changing directory to the Desktop. It worked correctly, the error message you mentioned does not occur.

I also tried with a fresh Explorer window (not started from Git Bash). Same thing.

I even ran unix2dos test.sh and then double-clicked it again. Another succeeded run.

So something must be different between your setup and mine.

FWIW when I export the same registry, it looks different:

[HKEY_CLASSES_ROOT\sh_auto_file\shell\open\command]
@="\"C:\\Program Files\\Git\\git-bash.exe\" --no-cd \"%L\" %*"

In other words, my Git is installed into Program Files while yours is in Development. Now, this might not make any difference, but it reminds me that you did not specify anything about your setup, and you obviously have a non-standard setup (most users never change the install path, on Windows 10 I do not even know how you would change it because that page is not shown in the installer.)

So: may I get more details, please? Ideally precise enough that I can replicate as similar a setup as possible so I have a prayer of reproducing the issue.

[Lunatrius]

I upgraded from 1.9.4-preview, no idea about the exact version. Previous versions allowed the installation path to be changed and updating to the latest (2.5.3) seemed to have preserved that setting. I'm on Windows 8.1 x64, installed the 32-bit version of git-for-windows.

The options picked during the install/update were:

• bash shell (default)
• cmd instead of mintty
• check-out windows, check-in unix

I get the same error message, even if I run the following via the run dialog WIN+R:

"C:\Development\Git\git-bash.exe" --no-cd "C:\Users\Lunatrius\Desktop\test.sh"

[Lunatrius]

I performed a few tests in a Win7 x64 VM using the 32 bit installer.

Error 1: The filename, directory name, or volume label syntax is incorrect.
Error 2: 'C:\Program' is not recognized as an internal or external command, operable program or batch file.

Test 1: double click
Test 2: "$INSTALL_LOC\git-bash.exe" --no-cd C:\User\VM\Desktop\test.sh
Test 3: "$INSTALL_LOC\git-bash.exe" --no-cd "C:\User\VM\Desktop\test.sh"

Install Location	Terminal	Test 1	Test 2	Test 3
C:\Development\Git	cmd	Error 1	works	Error 1
C:\Development\Git	mintty	works	works	works
C:\Program Files (x86)\Git	cmd	Error 2	works	Error 2
C:\Program Files (x86)\Git	mintty	works	works	works

I also tested using the syntax from test 2 on my normal install (the one previously mentioned) and it worked. Looks like a double quotes issue with the windows command prompt?

[dscho]

Thanks for the detailed analysis! I will have a look tomorrow trying to reproduce the error. Right now I cannot because I am on a phone... ☺

[Lunatrius]

Just used ProcessMonitor to check how exactly the process is created. These were generated by double clicking the batch/bash files:

C:\WINDOWS\system32\cmd.exe /c ""C:\Users\Lunatrius\Desktop\test.bat" "
C:\WINDOWS\system32\cmd.exe /C "C:\Development\Git\usr\bin\bash.exe" --login -i "C:\Users\Lunatrius\Desktop\test.sh" 

Running the following command from the run dialog started up the bash script as expected (added the "missing" double quotes):

C:\WINDOWS\system32\cmd.exe /C ""C:\Development\Git\usr\bin\bash.exe" --login -i "C:\Users\Lunatrius\Desktop\test.sh" "

[dscho]

I think I completely forgot to ask whether the script actually ran, the flashing window notwithstanding? I could actually understand if it did that; the current idea is that shell scripts might want to interact with the user, so they have to have a console window, but if they do not interact -- and finish fast -- the user would only see a flashing glimpse of the console window...

[dscho]

BTW I can finally reproduce, thanks to the crucial information that this bug affects only the ConHost option. Thanks @Lunatrius for bringing this to my attention.

[b9chris]

The script doesn't run when this bug occurs - you just get the error message in a flash of a window and it's gone.

In our case the scripts were files that do basic things like pull git submodules:

#!/bin/bash -v
git submodule foreach git pull origin master

If it ran we'd see the effects of this running - pulled submodules. No dice.

[dscho]

@b9chris hopefully you understand that my comment:

Our guide lines indicate pretty clearly that complete examples are preferred to incomplete ones.

was intended to elicit crucial information such as your decision to deviate from the default options in the installer by choosing the Windows console instead of the mintty one?

That omission cost both of us quite a bit of time.

Happily, @Lunatrius filled in the missing link and everything is groovy now.

Well, not everything. Every bug report is concluded successfully only when the original poster can confirm that the proposed fix is actually working for her.

So here is your chance to bring this ticket to a successful conclusion: install the tentatively-fixed version from this temporary installer:

https://github.com/dscho/build-extra/releases/download/tmp-conhost-git-bash/Git-2.5.3-sh-assoc-64-bit.exe

and test again, then report back whether it fixes the bug or not.

[dscho]

I really hate it when I spend hours and hours to fix problems that are not even mine and then those whose problem it is cannot even be bothered to test my fix.

So I have to merge it untested. Grmbl. No brownies from me.