What version of Go are you using (go version)?

go version go1.7.4 linux/amd64

(but same behaviour observed at tip)

What operating system and processor architecture are you using (go env)?

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GORACE=""
GOROOT="/home/myitcv/gos"
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build336417079=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?

Place the code found here https://play.golang.org/p/PKeAQFaVSe in a package directory called playground and then run:

cd /path/to/playground
go build && PATH=.:$PATH HELLOWORLD="hello world" go generate

What did you expect to see?

len(os.Args): 3, os.Args: []string{"playground", "main.go", "main.go"}
len(os.Args): 2, os.Args: []string{"playground", ""}
len(os.Args): 4, os.Args: []string{"playground", "hello", "world", "hello world"}

What did you see instead?

len(os.Args): 3, os.Args: []string{"playground", "main.go", "main.go"}
len(os.Args): 3, os.Args: []string{"playground", "", ""}
len(os.Args): 3, os.Args: []string{"playground", "hello world", "hello world"}

Maybe my bias arises from my understanding (or lack thereof) of the behaviour of bash etc in these situations, but I see two problems here:

• in the second instance, the unquoted $VARNOTSET should not have resulted in the empty string being passed as os.Args[1] to playground
• in the third instance, the unquoted $HELLOWORLD should have resulted in hello and world being passed as os.Args[2] and os.Args[3] respectively, not hello world

I stumbled across this because I was looking to use environment variables to pass common flags to my go generators (to adjust log levels). But when that environment variable is not set, the empty string is passed as an argument... and flag parsing stops just before the first non-flag argument, and the empty string matches that condition.

I can think of one workaround: putting these flag environment variables at the end of all my go:generate directives).. and then ensure my go generators do not do any handling of flag.Args() (or equivalent).

Assuming for one second the current behaviour is not desirable/expected, I can't actually think of a good solution here that is backwards compatible...

cc @robpike perhaps?