Comment 1:

"go run" is intended for playing and learning more than anything.  I wouldn't be
surprised if this is closed "Working As Intended".  There is a general resistance to
adding complexity with new options or environment variables.

Comment 2:

For clarity: to get around this, it's opening _go_.6 (found via glob to be architecture
independent) in the filepath.Dir(os.Args[0]) and then looking with a regexp to find the
source file used to define package main, which works when main is one file, rather than
the result of everything in the directory.
As Brady puts it, "jank".  I can write it, I'd rather not maintain it.  :)
While "go run" may be intended for playing, it's also the easiest way to run a tool
written as a single Go file, so people will end up using it anyway.  I like Go for its
pragmatism, instead of telling folks they're doing it wrong by using the way set up to
be easiest.  I can document "build first, or run from same directory", but in practice,
that just results in pain and stalls when developers are trying to focus on something
else.  Rather than interrupt their mental flow, I added jank.
If we can just get the list of original gofiles in an environment variable, while
running under "go run", it looks much more like existing concepts such as
$SSH_ORIGINAL_COMMAND, $SUDO_COMMAND and is _reducing_ complexity by restoring the
information that would normally be available via os.Args[0] but has otherwise been
removed by the "go run" intermediation.
Thanks.

Comment 3 by brady@apcera.com:

Another completely reasonable approach would be to make a constant in the binary that I
can get too. runtime.OrigionalCommandLine or some such.. It need not be an environment
variable, though I think thats the more typical approach...

Comment 4:

This sounds the underlying use case is not related to go run, but for the executable
being run to be able to discover the absolute path to itself. 
If so, this is issue, https://golang.org/issue/4057

Comment 5 by brady@apcera.com:

I just thought of a much easier and cleaner way to do this for our use case, though the
command line would still be nice.. but for anybody following along at home the following
code in main() will return the file name containing main() =)
brady@viper tmp$ cat /tmp/a.go 
package main
import(
    "fmt"
    "runtime"
)
func main() {
    _, file, _, _ := runtime.Caller(0)
    fmt.Println(file)
}
brady@viper tmp$ go run a.go
/tmp/a.go
This is a much cleaner and cheaper way of opening the file and is far, far less janky.
I still like the idea of an environment variable, but this can reduce our immediate
nasty jank factor. =)

Comment 6:

The problem is that the absolute path to the executable, in the `go run` case, is in the
temporary work dir, not the location where the source is.
Comment #6 on 4057 is accurate: "finding asset files accompanying the executable", but
also in the "from the source dir" case.

Comment 7:

I intend to close this issue as "working as intended" in the next 24 hours. Please speak
up if you wish to add any new information.

Status changed to WaitingForReply.

Comment 8 by brady@apcera.com:

It may work as intended but I still argue that the intention is messy. Having some
mechanism to find out what the command line used to run the go program is very useful if
for nothing other than help messages. There is some jank to make this slightly easier,
but this is something that I feel should be in either a variable, or accessible in some
way to the program since its something that every other language provides.

Comment 9:

Yes, it is messy but I think you're expecting too much of go run. As Brad said, go run
is just for experimentation, please don't expect it to move mountains. 
For the more general requirement of figuring out the path of the binary that is
executing this program, not os.Args[0], please refer to issue #4057.

Status changed to WorkingAsIntended.