New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/review/git-codereview: "sh": executable file not found in %PATH% error in TestSubmitInteractive #13406
Comments
Are you sure git is invoking sh.exe? Because of the strcspn in https://github.com/git/git/blob/aa826b651ae3012d1039453b36ed6f1eab939ef9/run-command.c#L161, I think git may be starting vim.exe directly. Does it work in Go on Windows to do, e.g.,
? If so, I can just follow git's logic a little more closely. |
I created little repo so I can immitate "git rebase -i" command, and then used "Process Explorer" (https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) to view process tree: git rebase -i master Please note that neither "C:\Program Files\Git\bin" nor "C:\Program Files\Git\share\vim\vim74" is in my PATH. Mind you it appears I can run "sh" from my command line, and it starts running "C:\Program Files\Git\bin\sh.exe". I don't understand how that happens, I suspect "git" program installed some hook (dll) on my system during its installation to intercept calls like that. I have no other explanation. I don't know of any other program that does that.
I agree, git is doing funny buggers under the covers.
"git var GIT_EDITOR" says "vi". But I cannot run vi from command window:
Same will happen, if I try to run your program. Alex |
I'd forgotten that git rebase is (frighteningly) entirely written in shell, so it's not going through prepare_shell_command at all. I would guess it's the git binary itself seeing that git-rebase is a shell script and invoking the baked-in sh.exe. Just to make sure I understand, if you start "C:\Program Files\Git\bin\sh.exe" by hand, what do you get for
? I'm not sure what the right answer here is. What would people expect in a Windows environment? Should we just disable this test on Windows? |
I get:
I am certainly not a git expert. I suppose if you need an editor available on any Windows computer, you cannot go past "notpead". It is very basic and noone uses it, but you can open a text file with it to allow editing. I don't expect it to return any useful exit code. And it is GUI program (not command line). Maybe it is possible to invoke git shell via git command somehow?
I have no problem with that. But it also means that "git submit -i" is broken too. Isn't it? Mind you, I don't use that facility myself. Alex |
CL https://golang.org/cl/18557 mentions this issue. |
Updates golang/go#13406 Change-Id: Iadc8586253e794947f5048676d317f55bd1d6b62 Reviewed-on: https://go-review.googlesource.com/18557 Reviewed-by: Austin Clements <austin@google.com>
The test is fixed. That may be the best we can do. |
I don't think so. I have added to skip TestSubmitInteractive on winodws in CL 18557. But the test is still broken.
Yes, I don't see way to improve TestSubmitInteractive. But I am also concerned that, perhaps, "git submit -i" doesn't work on windows too. If someone tell me how I can test "git submit -i" manually, I will try it on my windows computer. Alternatively we can just document that "git submit -i" is not supported on windows. Or we can also do nothing too. Alex |
I don't know how to test it all the way without a Gerrit instance (or a fake Gerrit instance like the tests make), but you can test the interactive part by just running "git submit -i" in the Go repository. You can even just be on master without any extra commits. It should just bring up an editor with an empty submit list and some comments explaining what you could do if there was something in the list. |
It does that. I guess we should just leave everything as is. Alex |
Interesting. Does running "git-codereview submit -i" directly work (without invoking it through the git alias)? I wonder if git sets up some environment before invoking the alias that makes submit -i work, but that isn't set up in the test. |
Alex |
Ah hah, so git is adding stuff to PATH when it runs an alias. That's missing in the test, so it fails. The only thing I see if obviously adding is the compiled-in
The second one works on Unix and I think git will run the alias with its built in POSIX shell, so it should be the same on Windows. If it doesn't work, you may need to tweak it by changing Also, is there a sh.exe in the exec path printed by the fist one? |
There is no sh.exe there, but there are many others:
Alex |
Hmm. That clearly didn't work. It looks like it split the arguments on the space after echo. How do you quote things in command prompt so they get passed as one argument and not expanded? Does |
I don't think you really want to know. But, if interested, search http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx for cmd.exe.
It does indeed:
I will add my PATH for completeness:
Alex |
|
Yikes!
Based on this, I'm guessing that MingW is actually what's putting some sh.exe in git's PATH. Unfortunately, I think that also means there's no good way to fake it in the git-codereview test short of some gnarly hack like the aliased PATH echo that I don't think we want to do. |
SGTM |
Our builders fails http://build.golang.org/log/688066e2307059052f9a0bd805045467b1edf181 with:
From what I can gather, CL 16677 assumes that sh (and vim) are found in the PATH. Not so on my computer (and builders too). I tried running "git rebase -i" command. And that, obviously, finds and executes git.exe, which then finds (I don't know how) and executes both sh.exe and vim.exe.
I don't see how we can implement this on windows. I don't use git-codereview on windows. Not for submitting anyway. So I am happy just to let this go. And skip failing test. Unless others have some good ideas.
/cc @aclements
Alex
The text was updated successfully, but these errors were encountered: