Closed
Description
Apply this diff:
diff --git a/src/pkg/os/exec/exec_test.go b/src/pkg/os/exec/exec_test.go
--- a/src/pkg/os/exec/exec_test.go
+++ b/src/pkg/os/exec/exec_test.go
@@ -687,3 +687,23 @@
os.Exit(2)
}
}
+
+func TestWindowsRelativeCommandWithoutExtention(t *testing.T) {
+ cd, err := os.Getwd()
+ if err != nil {
+ t.Fatalf("Getwd: %v", err)
+ }
+ defer os.Chdir(cd)
+
+ bindir := filepath.Join(runtime.GOROOT(), "bin")
+ err = os.Chdir(bindir)
+ if err != nil {
+ t.Fatalf("Chdir(%v): %v", bindir, err)
+ }
+ // the file name is actually go.exe on windows
+ cmd := exec.Command("./go", "env")
+ out, err := cmd.CombinedOutput()
+ if err != nil {
+ t.Errorf("cmd failed: %v %v", err, string(out))
+ }
+}
to hg id b5eda189b974
and run the test. It should succeed, but fails on windows with:
C:\go\root\src>u:\test -test.v -test.run=Exten
=== RUN TestWindowsRelativeCommandWithoutExtention
--- FAIL: TestWindowsRelativeCommandWithoutExtention (0.00 seconds)
exec_test.go:707: cmd failed: fork/exec ./go: The system cannot find the file specified.
FAIL
The problem is introduced by:
os/exec: fix Command with relative paths
Command was (and is) documented like:
"If name contains no path separators, Command uses LookPath to
resolve the path to a complete name if possible. Otherwise it
uses name directly."
But that wasn't true. It always did LookPath, and then
set a sticky error that the user couldn't unset.
And then if cmd.Dir was changed, Start would still fail
due to the earlier sticky error being set.
This keeps LookPath in the same place as before (so no user
visible changes in cmd.Path after Command), but only does
it when the documentation says it will happen.
Also, clarify the docs about a relative Dir path.
No change in any existing behavior, except using Command
is now possible with relative paths. Previously it only
worked if you built the *Cmd by hand.
Fixes issue #7228
LGTM=iant
R=iant
CC=adg, golang-codereviews
https://golang.org/cl/59580044
The problem was first discovered when 48a4a9afb88b failed on windows. I also think that
our current windows-386 builder is broken for the same reason. It outputs:
fork/exec c:\gobuilder\windows-386-ec2-b5eda189b974\go\bin\go: The system cannot find
the file specified.
for every subrepo build.
Alex