Comment 1:

Labels changed: added repo-main.

Comment 2:

You have a file named \x.go?
\ is the path separator in windows, if you somehow managed to name a file with it,
you're doing it wrong.
Otherwise you can just use : go run x.go

Comment 3:

\x.go is not an absolute path. c:\x.go is. Every absolute path (with some exceptions)
must start with drive letter. For example, if you computer has 2 drives c: and d:, which
file does \x.go refer to? c:\x.go or d:\x.go?
\x.go is OK as relative path. Drive letter is part of "current directory", for example
C:\>cd %GOROOT%
C:\go\root>cd
C:\go\root
C:\go\root>
So, if my current directory is C:\go\root, then \x.go would be referring to C:\x.go.
Could you, please, provide more details why you think we have a bug here. Thank you.
Alex

Status changed to WaitingForReply.

Comment 4:

Yes, it's in a weird middle ground between absolute and relative, so maybe ignore the
wording I used in the summary. The point is that \x.go should refer to x.go in the root,
not x.go in the current directory.
I was in c:\rsc\go\src\pkg\runtime. I ran 'go run \x.go' and the go command told me it
could not open c:\rsc\go\src\pkg\runtime\x.go. That's the right error for 'go run x.go',
not for 'go run \x.go'. What I typed should have resolved to c:\x.go and did not.
Russ

Status changed to Accepted.

Comment 5:

It's a bug.
At tip:
Microsoft Windows [Version 6.1.7601]
C:\>go version
go version devel +c9966d8852a5 Mon Jun 02 16:26:08 2014 +1000 windows/amd64
The file C:\drive.go is empty and only exists in directory C:\:
C:\>dir drive.go
 Directory of C:\
06/02/2014  10:29 AM                 0 drive.go
               1 File(s)              0 bytes
               0 Dir(s)  69,797,081,088 bytes free
C:\>cd \gopath\src
C:\gopath\src>dir drive.go
 Directory of C:\gopath\src
File Not Found
C:\gopath\src>dir \drive.go
 Directory of C:\
06/02/2014  10:29 AM                 0 drive.go
               1 File(s)              0 bytes
               0 Dir(s)  69,396,221,952 bytes free
C:\gopath\src>dir c:\drive.go
 Directory of c:\
06/02/2014  10:29 AM                 0 drive.go
               1 File(s)              0 bytes
               0 Dir(s)  69,396,324,352 bytes free
The command go run doesn't find file \drive.go. It should.
C:\gopath\src>go run drive.go
GetFileAttributesEx drive.go: The system cannot find the file specified.
C:\gopath\src>go run \drive.go
open C:\gopath\src\drive.go: The system cannot find the file specified.
C:\gopath\src>go run c:\drive.go
c:\drive.go:1:1: expected 'package', found 'EOF'
As expected, the test program 8130.go finds the file \drive.go:
package main
import (
    "fmt"
    "os"
)
func file(name string) {
    f, err := os.Open(name)
    if err != nil {
        fmt.Println(err)
        return
    }
    defer f.Close()
    fmt.Println(f.Name())
}
func main() {
    file(`drive.go`)
    file(`\drive.go`)
    file(`c:\drive.go`)
}
C:\gopath\src>go run 8130.go
open drive.go: The system cannot find the file specified.
\drive.go
c:\drive.go
The path \drive.go is an absolute path: "a file name that begins with a single
backslash, for example, '\file.txt'".
Naming Files, Paths, and Namespaces
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247.aspx
Paths
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247.aspx#paths
A file name is relative to the current directory if it does not begin with one of the
following:
    A UNC name of any format, which always start with two backslash characters ("\\"). For more information, see the next section.
    A disk designator with a backslash, for example "C:\" or "d:\".
    A single backslash, for example, "\directory" or "\file.txt". This is also referred to as an absolute path.

Attachments:

1. 8130.go (254 bytes)

Comment 6:

Started CL. Will submit when Go 1.4 opens for CLs.

Comment 7:

> ... it's in a weird middle ground between absolute and relative, ...
We cannot have that. filepath must make that call one way or the other.
> ... I was in c:\rsc\go\src\pkg\runtime. I ran ...
I can see your problem now. It is because of this logic in
http://tip.golang.org/src/cmd/go/build.go#L506. filepath.IsAbs(`\x.go`) returns false
(because the path does not have drive letter), so the code filepath.Join it with current
directory. I think we should just call filepath.Abs here instead. Interestingly,
filepath.Abs has the same problem https://golang.org/issue/8145. I
propose we fix filepath.Abs and use it in cmd/go. How does that sound to you?
Alex

Comment 8:

I think maybe filepath.IsAbs should return true for \x.go.
IsAbs == false is supposed to mean 'this path is relative to the current directory'.
And that is not the case here.

Comment 9:

To be clear, nothing is going to happen for 1.3 so we have some time to figure this out.

Comment 10:

> I think maybe filepath.IsAbs should return true for \x.go.
I disagree. See below.
> IsAbs == false is supposed to mean 'this path is relative to the current directory'.
I don't think this would always work, for example, is 'x:a\b' relative to the current
directory? '\x.go' is relative to current drive, but absolute to current directory on
that drive. It becomes complicated quickly. I would use different description -
'absolute path will still work even after current directory / drive letter is changed'.
I think we have a few other issues like that in path/filepath. For example, filepath.Rel
is broken when different drive letters. Running
package main
import (
    "fmt"
    "path/filepath"
)
func rel(path, base string) {
    p, err := filepath.Rel(base, path)
    fmt.Printf("path=%v base=%v p=%v err=%v\n", path, base, p, err)
}
func main() {
    rel(`c:\go\root`, `c:\go\`)
    rel(`c:\go\root`, `x:\`)
    rel(`c:\go\root`, `x:`)
}
outputs
path=c:\go\root base=c:\go\ p=root err=<nil>
path=c:\go\root base=x:\ p= err=Rel: can't make \go\root relative to \
path=c:\go\root base=x: p= err=Rel: can't make \go\root relative to
I was going to create an issue for it, but I don't see how we can improve the situation
here.
> ... nothing is going to happen for 1.3 ...
Sure.
Alex

Comment 11:

CL https://golang.org/cl/143200043 mentions this issue.

Comment 12:

This issue was closed by revision 0b8bc7c.

Status changed to Fixed.