Problem with `go run *.go` in windows CMD - winapi error #123

[Dawid Polak]

Hi. I have problem with run go run command from windows CMD.

Standard dev command 

 > go run *.go

generate error

 > GetFileAttributesEx *.go: winapi error #123

At this moment on windows i must use alternative console  (for example MINGW32) for normal workflow, but as I know - many new developers had this problem, and nowhere in google any info about this. 

(windows 7, x64) 

[minux]

On Thu, Jan 31, 2013 at 12:15 AM, Dawid Polak <da...@mentax.pl> wrote:

Hi. I have problem with run go run command from windows CMD.

Standard dev command 

 > go run *.go

"go run" doesn't support expanding '*', so you will have to expand *.go to a list of go filenames.

This is not a problem of Go itself, as Windows cmd doesn't expand the wildcard.

btw, if you're using more than one file for the main package, why not follow

http://golang.org/doc/code.html and set up GOPATH and use go build/install?

generate error

 > GetFileAttributesEx *.go: winapi error #123

At this moment on windows i must use alternative console  (for example MINGW32) for normal workflow, but as I know - many new developers had this problem, and nowhere in google any info about this.

we don't require alternative console on windows. 

(windows 7, x64) 

[Dawid Polak]

> This is not a problem of Go itself, as Windows cmd doesn't expand the wildcard.

I know. But documentation should mention more abut this limitation. 

> btw, if you're using more than one file for the main package, why not follow

> http://golang.org/doc/code.html and set up GOPATH and use go build/install?

Of course - i have - but many times go run is used for test run only, and simple - is faster. 

> we don't require alternative console on windows. 

But maybe documentation should suggest this solution, or in 'go run' implement alternative command line parameter format - for example  " go run ' *.go '  "

[minux]

On Thu, Jan 31, 2013 at 1:26 AM, Dawid Polak <da...@mentax.pl> wrote:

> This is not a problem of Go itself, as Windows cmd doesn't expand the wildcard.

I know. But documentation should mention more abut this limitation. 

> btw, if you're using more than one file for the main package, why not follow

> http://golang.org/doc/code.html and set up GOPATH and use go build/install?

Of course - i have - but many times go run is used for test run only, and simple - is faster. 

it is only faster if you only run the same set of program once.

probably you can create a script (or better, a Go program) to wrap the go tool and

expand wildcards in the argument (use path/filepath.Glob and os/exec for that task)

> we don't require alternative console on windows. 

But maybe documentation should suggest this solution, or in 'go run' implement alternative command line parameter format - for example  " go run ' *.go '  "

"go run" is only supposed to run single file commands for test purpose, so it even

don't support read the source code from stdin, because the authors' fear that people

will abuse that (however, as i frequently run sample programs from play.golang.org,

i do have a script for that).

[mattn]

it is only faster if you only run the same set of program once.

probably you can create a script (or better, a Go program) to wrap the go tool and

expand wildcards in the argument (use path/filepath.Glob and os/exec for that task)

Mingw32 uses __getmainargs in msvcrt.dll. So go can do it same. :)

http://play.golang.org/p/SYbK-MSVSN

[dat...@gmail.com]

I was also bit in the ass by this, would you guys please fix it?

[Dave Cheney]

I think you're expecting too much from go run. Please see Minix's comments from 2013, go run is just for short throw away examples. For anything more important, structure your code in packages inside GOPATH.

[as....@gmail.com]

How exactly do you propose this be fixed? Windows has a crippled shell that thinks programs should process and interpret their own asterisk characters. This turns into a major inconsistency across windows CLI tools. I dont think Go should tailor itself to badly designed plumbing.