Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

git_shell_ext64.dll makes Far Manager run git before running batch files #2

Closed
x-yuri opened this Issue · 20 comments

4 participants

@x-yuri

Far Manager executes the following command prior to running cmd/bat files when git_shell_ext64.dll is registered: git rev-parse --show-prefix.

@hvoigt
Owner

And your problem is?

Please explain in more detail what you are experiencing. What you expected and possibly a suggestion how to solve it.

@x-yuri

Let's consider this file (1.bat):

echo 1

When I press Enter on it, here is what happens:

...>1.bat
fatal: Not a git repository (or any of the parent directories): .git

...>echo 1
1

When I run it from command line though (type the name and press Enter), it works as expected (no git commands are executed before running a batch file). Probably you may add some way to prevent this behaviour for certain programs (environment variable?). But I don't know the reason behind this, so there may be better ways to fix it.

@hvoigt
Owner

Could you have a look at https://github.com/msysgit/Git-Cheetah/tree/hv/read_output_from_tools whether that fixes your issue.

@x-yuri

I have a hard time building it from sources. I'm using mingw-w64 (gcc-4.7.2, rubenvb) and msys. This is my first time building from sources using mingw, so I don't know if the problems I've faced are to be expected.

First, I run make. And it says cc: Command not found. Judging from common/Makefile, it means it isn't going to build 64-bit version. Then I run W64=1 make. And it says: /src/mingw-w64/sysroot/bin/x86_64-w64-mingw32-gcc.exe: Command not found. Then I run W64=1 cross=c:/programs/mingw-w64-rubenvb/bin/x86_64-w64-mingw32- make, but result is the same. It doesn't allow me to override cross variable. Am I doing it wrong?

@hvoigt
Owner

Please use the msysgit build environment. You can find it in the right column here:

http://msysgit.github.com/

and download it from here: http://code.google.com/p/msysgit/downloads/list?q=net+installer

After installing you will find git-cheetah under /src/git-cheetah and you should be able to test install cheetah using

cd /src/git-cheetah
git checkout origin/hv/read_output_from_tools
make install

@x-yuri

First, the problem with git_shell_ext64.dll arises apparently when using 64-bit version of far manager. msysgit build environment compiles 32-bit version of aforementioned dll. I don't know if it makes any difference. I'm able to check if it works in 32-bit version of far manager anyway. But then, the dll doesn't get registered somehow (make install): I can't find it in registry and I can't see it in procmon. No errors are printed during install. I even tried to register it by hand: regsvr32 git_shell_ext.dll.

@dscho
Owner

@x-yuri you can make the 64-bit version by using make W64=1 install. This might require to have called /src/mingw-w64/release-easy.sh first, I do not remember the details. Feel free to add appropriate information to our Wiki so others do not fall into the same situation as you did.

@x-yuri

You were right about running /src/mingw-w64/release-easy.sh first in order to compile 64-bit version of dll. I've managed to build both versions, but none of them get installed. I can't find get_shell_ext anywhere in registry. Here is the output of make W64=1 install.

@x-yuri

Here is some more info, the code which produces the error message if compiled for 64-bit architecture:

#define UNICODE
#include <windows.h>
#include <shellapi.h>

int wmain(int argc, wchar_t* argv[])
{
    SHELLEXECUTEINFO sei = {sizeof(sei)};
    sei.lpFile = argv[1];
    sei.lpVerb = L"open";
    sei.fMask = SEE_MASK_INVOKEIDLIST;
    ShellExecuteEx(&sei);
}

If either lpVerb, or fMask is commented out, no error message is shown (no git command is executed).

@VictorVG

And I was shown this error when using 32 bit MsysGit (Git-1.8.4-preview 20130916, git_shell_ext.dll version v0.1.0-rc1-79-g1c2f90e) when run from the console of any programs and scripts... I resolved this problem use UNIX-like style command:

cd /d "C:\Program Files\Git\git-cheetah"&&regsvr32 /u git_shell_ext.dll

DLL path "C:\Program Files\Git\git-cheetah\git_shell_ext.dll".

@VictorVG

Yes, the subsequent verification of the problem has been resolved. Source is in error git_shell_ext.dll 32/64 bit builds - that it spoils the console buffer and needs work ...

@hvoigt
Owner

So did anyone try my branch as a solution? It does not seems so from the comments. As I am not a git-cheetah console user I need someone to test.

@x-yuri

@hvoigt for that I need someone to help me install it. On a side note, I'm not a git-cheetah user either. I don't even know what it does. It just gets in the way when I'm trying to run git from console.

@dscho
Owner

@x-yuri Git-Cheetah is a Windows Explorer extension that adds a Git-specific context menu.

From your make W64=1 install output it looked as if it was installed alright.

Since you reported the problem, you would be in the perfect position to try out https://github.com/msysgit/Git-Cheetah/tree/hv/read_output_from_tools that @hvoigt so nicely made just for your sake.

To try it out, you will need to call these commands:

cd /src/git-cheetah/
git fetch https://github.com/msysgit/Git-Cheetah/ read_output_from_tools
git checkout FETCH_HEAD
make W64=1 install

After that, you should have the patched Git-Cheetah installed and the issues you reported should be gone.

If not, I'd strongly suggest to work with @hvoigt on resolving the issue, providing as much assistance from your side, because at the moment, @hvoigt is working for you, for free, and he might not do that for all eternity.

@x-yuri

I didn't mean to be rude, if anything. But from my point of view it looks like I'm trying to make this git-cheetah thing better. I've spent quite a lot of time on reporting this issue, for free. And I very seldom use git from command line under windows. And it's a luck I'm even under windows now. Normally, I'd be under linux. In other words, resolving this issue doesn't make my life any better. So when people suddenly stopped responding to this issue, I was somewhat disappointed. Now then, let me try again...

@x-yuri

And here what I've got:

$ make W64=1 install
...
/src/mingw-w64/sysroot/bin/x86_64-w64-mingw32-dllwrap.exe -Wl,--enable-stdcall-fixup  --def git_shell_ext.def \
                ../common/cheetahmenu.o ../common/date.o ../common/debug.o ../common/exec.o ../common/menuengine.o ../common/sha1_file.o ../common/strbuf.o ../common/usage.o ../common/wrapper.o ext.o dll.o factory.o menu.o systeminfo.o registry.o columns.o cheetah.o ../compat/mingw.o ../compat/mmap.o ../compat/pread.o ../compat/strlcpy.o ../compat/winansi.o -o git_shell_ext64.dll \
                -luuid -loleaut32 -lole32 -lws2_32
regsvr32 -s -n -i:machine C:\\\\msysgit\\\\src\\\\git-cheetah\\\\explorer\\\\git_shell_ext64.dll
make[1]: Leaving directory `/src/git-cheetah/explorer'

But this dll doesn't get installed. Or so I think. Because in the registry I see only records concerning the other git installed:

[HKEY_CLASSES_ROOT\CLSID\{ca586c80-7c84-4b88-8537-726724df6929}\InProcServer32]
@="C:\\Program Files (x86)\\Git\\git-cheetah\\git_shell_ext64.dll"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{ca586c80-7c84-4b88-8537-726724df6929}\InProcServer32]
@="C:\\Program Files (x86)\\Git\\git-cheetah\\git_shell_ext64.dll"
[HKEY_USERS\S-1-5-21-3480339654-2671789629-1610522028-1001\Software\Classes\CLSID\{ca586c80-7c84-4b88-8537-726724df6929}\InProcServer32]
@="C:\\Program Files (x86)\\Git\\git-cheetah\\git_shell_ext64.dll"
[HKEY_USERS\S-1-5-21-3480339654-2671789629-1610522028-1001_Classes\CLSID\{ca586c80-7c84-4b88-8537-726724df6929}\InProcServer32]
@="C:\\Program Files (x86)\\Git\\git-cheetah\\git_shell_ext64.dll"

And apparently issue isn't fixed, those git messages still appear.

@dscho
Owner

On Thu, 2 Jan 2014, x-yuri wrote:

regsvr32 -s -n -i:machine C:\\\\msysgit\\\\src\\\\git-cheetah\\\\explorer\\\\git_shell_ext64.dll
make[1]: Leaving directory `/src/git-cheetah/explorer'

So that worked. (You may want to use make W64=1 install-user instead,
though.)

But this dll doesn't get installed. Or so I think. Because in the
registry I see only records concerning the other git installed:

[HKEY_CLASSES_ROOT\CLSID\{ca586c80-7c84-4b88-8537-726724df6929}\InProcServer32]
@="C:\\Program Files (x86)\\Git\\git-cheetah\\git_shell_ext64.dll"
[HKEY_CURRENT_USER\Software\Classes\CLSID\{ca586c80-7c84-4b88-8537-726724df6929}\InProcServer32]
@="C:\\Program Files (x86)\\Git\\git-cheetah\\git_shell_ext64.dll"
[HKEY_USERS\S-1-5-21-3480339654-2671789629-1610522028-1001\Software\Classes\CLSID\{ca586c80-7c84-4b88-8537-726724df6929}\InProcServer32]
@="C:\\Program Files (x86)\\Git\\git-cheetah\\git_shell_ext64.dll"
[HKEY_USERS\S-1-5-21-3480339654-2671789629-1610522028-1001_Classes\CLSID\{ca586c80-7c84-4b88-8537-726724df6929}\InProcServer32]
@="C:\\Program Files (x86)\\Git\\git-cheetah\\git_shell_ext64.dll"

Maybe you should uninstall them first. It is quite conceivable that
regsrv32 sees that the versions match and refuses to replace the
extension.

And apparently issue isn't fixed, those git messages still appear.

Yes, as long as those other extensions are active, it is unlikely that
they will disappear, because the old Git Cheetah version is most likely
the culprit and will need to be deactivated before it will shut up.

@x-yuri

make W64=1 install-user - that's it. With this it works, without git messages, the built dll is loaded in the far process. So I take it, hv/read_output_from_tools solves the issue.

Also, @dscho, you're missing one more command in your explanations:

cd /src/git-cheetah/
git fetch https://github.com/msysgit/Git-Cheetah/ read_output_from_tools
git checkout FETCH_HEAD
/src/mingw-w64/release-easy.sh
make W64=1 install
@dscho dscho closed this in a6c3759
@dscho
Owner

@x-yuri I assumed that you already had mingw-w64 installed because of your earlier log showing that you were able to compile and install Git Cheetah. Apparently I was mistaken, but then I wonder how that log came about.

Glad that it works for you! I merged the branch.

@x-yuri

Apparently I was mistaken, but then I wonder how that log came about.

I reinstalled windows after that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.