You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
git bash shell extensions use system32/cmd and wscript #8
If you enable "git bash here" during installation of msysgit on (at least one) XP64, then right click on a folder and select "git bash here" a window opens with the following traceback:
C:\Program Files (x86)\Git\bin\sh.exe: *** fork: can't reserve memory for stack
0x490000 - 0x690000, Win32 error 0
0 [main] sh.exe" 4292 sync_with_child: child 4308(0xE0) died before initia
lization with status code 0x1
322 [main] sh.exe" 4292 sync_with_child: *** child state waiting for longjmp
sh.exe": fork: Resource temporarily unavailable
sh.exe"-3.1$
However if you use the desktop icon or the start menu icon to start git bash, it works perfectly.
Welcome to Git (version 1.7.10-preview20120409)
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
myname@MYCOMPUTER ~
$
Also "git bash here" shell extension works fine on 32-bit windows XPSP3.
msysgit version 1.7.10-preview20120409
windows XP x64 Edition Version 2003 SP2
The problem seems to stem from the fact that the git bash.vbs runs using "C\WINDOWS\system32\wscript.exe" instead of "C\WINDOWS\sysWoW64\wscript.exe" which ironically runs the 32bit version
The same goes for "open" for file-types with the extension .sh, which use the system32 version of cmd instead of the syswow64 version of cmd.
I was able to run the vbs just by changing the opens with to the syswow64 version of wscript, but the shell extension still doesn't work.
Oddly enough, it works on (at least one) 64 bit version of Windows 7.
It would be nice if you could provide a patch to fix this on Win XP 64 Bit in the installer.
After installing the development environment msysgit have a look into
share/WinGit/install.iss
On roughly line 1118 there is the following:
(not RegWriteStringValue(RootKey,'SOFTWARE\Classes\Directory\shell\git_shell\command','','wscript "'+AppDir+'\Git Bash.vbs" "%1"')) then begin
You can use the 'isWin64' variable to check for a 64 Bit OS. I hope your solution will also work on Vista and Windows 7. Since I guess not many people have Win XP 64 Bit so you are probably the only person who can implement and test the fix for Win XP 64 Bit.
You can create an installer by running share/WinGit/release.sh
I do not see why this issue should be closed just because the reporter found a solution that works for him. We should only close issues when a fix has been committed and verified.
Sounds good. I was just too swamped this weekend to work on it, but I looked at his pull request, and it is basically the same fix (change the registry entry to use "windows/syswow64/wscript")
-----Original Message-----
From: hvoigt [mailto:[email protected]]
Sent: Wednesday, May 23, 2012 8:24 AM
To: Mark Mikofski
Subject: Re: [git] git bash shell extensions use system32/cmd and wscript (#8)
one thing that I haven't had time to look into yet is still the .sh file association on x64 is associated with with windows/system32/cmd.exe instead of windows/syswow64/cmd.exe, which is not a msysgit issue per se but more an issue for msys on x64. If I have time I'll look into it too.
FWIW, the "{syswow64}" constant in InnoSetup automatically expands to windows/syswow64 on 64-bit systems and windows/system32 on 32-bit, which might make fixing that association easier.
double clicking a shell script won't run it, even though it is associated with sh.exe
e.g. if a shell script contains the following on, then on windows 7 and XP(x86) double clicking starts a bash shell and then vim.
#! /bin/bash
vi
But on XP(x64) it opens up a window for an instant, which then closes, very similar to the problem for "Git Bash here" that is now solved thanks to rpavlik. I haven't had to troubleshoot it, but basically I think x86 commands need to be executed with c:\windows\syswow64\cmd.exe instead of c:\windows\system32\cmd.exe which is on the windows path.
Play around with Value Data (maybe adding the 32bit cmd.exe) so that it works for you and once you have a succesfully tested installer send us a pull request.
Got it! Just change the key (you can do this through regedit - but I assume you can also do it thru Tools > File Options > File Types > SH > Advanced > open > edit)
Adding C:\WINDOWS\SysWOW64\cmd /C and adding quotes around the entire string, because it will get expanded, and you want to keep it all together. The /C flag runs the string as a command line, and closes the command window after execution. Same as before change one key and the others (Wow6432Node) change automatically.
Tested with the shell file above
#! /bin/bash
vi
which I saved as vi.sh and then double clicked and voila, it works!
Activity
mikofski commentedon May 15, 2012
I edited the key to call the syswow64 version of wscript and the shell extension works now.
The other keys is updated automatically. That is
Wow6432NodeandHKEY_LOCAL_MACHINE\SOFTWARE\Classeshvoigt commentedon May 16, 2012
It would be nice if you could provide a patch to fix this on Win XP 64 Bit in the installer.
After installing the development environment msysgit have a look into
share/WinGit/install.iss
On roughly line 1118 there is the following:
You can use the 'isWin64' variable to check for a 64 Bit OS. I hope your solution will also work on Vista and Windows 7. Since I guess not many people have Win XP 64 Bit so you are probably the only person who can implement and test the fix for Win XP 64 Bit.
You can create an installer by running share/WinGit/release.sh
sschuberth commentedon May 16, 2012
I do not see why this issue should be closed just because the reporter found a solution that works for him. We should only close issues when a fix has been committed and verified.
mikofski commentedon May 16, 2012
I will work on the patch this weekend.
dscho commentedon May 17, 2012
@mikofski thanks!
hvoigt commentedon May 23, 2012
msysgit/msysgit#12
Has just been merged so we can close this issue as well.
mikofski commentedon May 23, 2012
Sounds good. I was just too swamped this weekend to work on it, but I looked at his pull request, and it is basically the same fix (change the registry entry to use "windows/syswow64/wscript")
-----Original Message-----
From: hvoigt [mailto:[email protected]]
Sent: Wednesday, May 23, 2012 8:24 AM
To: Mark Mikofski
Subject: Re: [git] git bash shell extensions use system32/cmd and wscript (#8)
msysgit/msysgit#12
Has just been merged so we can close this issue as well.
Reply to this email directly or view it on GitHub:
#8 (comment)
mikofski commentedon May 23, 2012
one thing that I haven't had time to look into yet is still the .sh file association on x64 is associated with with
windows/system32/cmd.exeinstead ofwindows/syswow64/cmd.exe, which is not a msysgit issue per se but more an issue for msys on x64. If I have time I'll look into it too.rpavlik commentedon May 24, 2012
FWIW, the "{syswow64}" constant in InnoSetup automatically expands to
windows/syswow64on 64-bit systems andwindows/system32on 32-bit, which might make fixing that association easier.hvoigt commentedon May 24, 2012
@mikofski: You are right that might need fixing as well. It is contained in the installer in the registry keys. Does it crash for you?
mikofski commentedon May 25, 2012
double clicking a shell script won't run it, even though it is associated with
sh.exee.g. if a shell script contains the following on, then on windows 7 and XP(x86) double clicking starts a bash shell and then vim.
But on XP(x64) it opens up a window for an instant, which then closes, very similar to the problem for "Git Bash here" that is now solved thanks to rpavlik. I haven't had to troubleshoot it, but basically I think x86 commands need to be executed with
c:\windows\syswow64\cmd.exeinstead ofc:\windows\system32\cmd.exewhich is on the windows path.hvoigt commentedon May 25, 2012
@mikofski: Have a look in install.iss at around line 120 and 127:
There are two keys that contain this:
Play around with Value Data (maybe adding the 32bit cmd.exe) so that it works for you and once you have a succesfully tested installer send us a pull request.
mikofski commentedon Jun 7, 2012
Got it! Just change the key (you can do this through regedit - but I assume you can also do it thru Tools > File Options > File Types > SH > Advanced >
open> edit)Adding
C:\WINDOWS\SysWOW64\cmd /Cand adding quotes around the entire string, because it will get expanded, and you want to keep it all together. The/Cflag runs the string as a command line, and closes the command window after execution. Same as before change one key and the others (Wow6432Node) change automatically.Tested with the shell file above
which I saved as vi.sh and then double clicked and voila, it works!
Now on to the installer/iss file ...
mikofski commentedon Jun 7, 2012
Pull request sent; see msysgit/msysgit issue #26
Merge pull request #8 from dscho/mingw-prefix