os/exec: Cmd does not attempt to run ./prog.exe, when execution of ./prog requested

[alexbrainman]

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

[alexbrainman]

Comment 1:

https://golang.org/cl/83020043/

Status changed to Started.

[bradfitz]

Comment 2:

*** Submitted as https://code.google.com/p/go/source/detail?r=0bf0c11aea78 ***

Status changed to Fixed.