os/exec: on Windows, LookPath sometimes improperly returns ErrDot

[dkess]

Caused by the changes in https://go.dev/cl/403274.

When using LookPath to lookup an executable which is both in the current working directory and in the PATH, it returns an ErrDot, which is improper since the chosen path is still in the PATH.

Example: consider exec.LookPath("netsh"). When run from a "normal" working directory (C:\Users\MyUser), this correctly returns "C:\Windows\system32\netsh.exe", nil. But if the working directory is C:\Windows\system32, it returns the relative path with ErrDot.

This can subtly break any Go program that calls system32 executables that don't specify the full path, which is a common pattern.

An more concrete example from Google code: https://github.com/google/winops/blob/89df70d833b79d5b41af14ad1070df6ce09a5086/powershell/powershell_windows.go#L37. This would break if the current working directory is C:\Windows\system32 (which happens to be the default working directory of an administrator cmd window).

[bcmills]

The fix seems easy enough — if we would return ErrDot, we could first check to see whether the same path is also an absolute entry in %PATH%. If it is, we can return the absolute version instead of the relative one.

That's still a (very minor) semantic change compared to prior versions of Go — in prior versions we would return the relative path instead of the absolute one — but that seems acceptable to me because the two paths still refer to exactly the same executable.

@golang/windows, does that sound right?

[gopherbot]

Change https://go.dev/cl/414054 mentions this issue: os/exec: on Windows, suppress ErrDot if the implicit path matches the explicit one

[bcmills]

Should be fixed at HEAD, and in the next beta or RC. @dkess, thanks for testing early and reporting it!