assuming . is in your path

Is that true anywhere except for Windows?

The idea of a tool deleting things that I've previously asked it to build makes me nervous. I suppose if I want it to stick around, I can always run "go build -o mycmd.keep".

Will it check that my PWD is actually that of the package I'm go installing, so it doesn't accidentally delete another binary of the same name in whatever directory I'm currently in? What if I'm currently in $GOPATH/bin, will it first install the binary, then delete it directly afterwards? Or will go install only delete the binary if I don't pass it an import path?

And, since Go is now supposed to decide for me what is stale and what isn't, will running go test delete a *.test file previously created by go test -c?

I find this behavior strange and surprising. It seems out of scope for go install.

I agree. If we do anything here, can you just see if "." is in their $PATH and contains the binary just installed, and then warn? I'd rather see a warning (as much as Go doesn't like them), than have something deleting things.

Not to mention that dot in PATH is only a problem if it comes before $GOPATH/bin, and generally speaking dot should only be the last element, due to security reasons, so I'm not sure this is really a big issue for most people.

But that binary there was the result of a GOOS=darwin go build && rsync mycmd macmini: && ssh macmini ./mycmd I was running in another terminal.

I'm sure I'm in absolute minority here, but I would love to see this implemented. Many times I wasted time because of this stale binary generated by go build. And yes, my PATH starts with ".".

On 21 January 2015 at 07:37, Aram Hăvărneanu notifications@github.com
wrote:

my PATH starts with ".".

Is this a plan9 thing?

I fail to see the problem here. If you have "." before $GOPATH/bin in your
path, you're asking for the old version. Don't do that. Put $GOPATH/bin
first in your path if you want to prefer the installed version.

On Tue, Jan 20, 2015 at 12:40 PM, Andrew Gerrand notifications@github.com
wrote:

On 21 January 2015 at 07:37, Aram Hăvărneanu notifications@github.com
wrote:

my PATH starts with ".".

Is this a plan9 thing?

—
Reply to this email directly or view it on GitHub
#9645 (comment).

The default (and only) Plan 9 $path is (. /bin), yes, but this predates Plan 9, it was the same in research unix.

I'd rather see a warning (as much as Go doesn't like them), than have something deleting things.

Well, go clean will delete it. I don't see why the set of things that go install is allowed to do is different than the set of things go clean is allowed to do.

Well, go clean will delete it. I don't see why the set of things that go install is allowed
to do is different than the set of things go clean is allowed to do.

That's a fair argument, except that I've never used go clean and it would be surprising if things started cleaning themselves.

Personally I would not like this behavior for the exact reason @bradfitz stated ("a tool deleting things that I've previously asked it to build").

But aside from that, I would argue that we should not support or encourage having . in your $PATH, as doing so is incredibly dangerous.
Consider the scenario where you download a tarball from the internet, you extract it, then cd into it and run ls. If that tarball had an executable ls in it, it would run. If that executable was malicious, it could do things such as trash your system (or whatever you have access to).

Let's keep this discussion focused on go build. It's nobody's business to encourage or discourage having . in PATH, and it's certainly not something the Go project should police.

Thanks.

Let's keep this discussion focused on go build. It's nobody's business to encourage or discourage having . in PATH, and it's certainly not something the Go project should police.

But isn't that the whole reason for this request? To fix the issue that can arise when people have . in $PATH. What other reason is there for this feature request?

Re $PATH:

(1) I'm pretty frustrated by the tone here, and I worry that if this is what new Go users encounter when they propose things, we may be turning away more people than I realized. I reported a real problem that I encounter regularly, and the response is basically like saying I'm holding my phone wrong. Please try to be more constructive in general.

(2) Having . in your PATH is not a "Plan 9 thing". It is a Unix thing. The original Bourne shell in 7th Edition Unix had a default path of ":/bin:/usr/bin" (see usr/src/cmd/sh/msg.c), the leading empty element meaning dot is searched first. Kernighan and Pike's The Unix Programming Environment talks about $PATH a half-dozen times over the course of the book, and every example has dot (implicitly) at the beginning. Searching the current directory in $PATH is a very common setting, even if it has fallen out of favor as the default in Linux distributions. So I'm not holding my phone wrong, thank you very much.

(3) I am aware of the oft-repeated security arguments. They don't prove I'm holding my phone wrong either.

Enough about $PATH.

To be very clear, let me restate the behavior I am proposing. Today, 'go build' with no arguments in a command directory foo writes a binary 'foo' (or foo.exe on Windows). 'go install' with no arguments in that directory writes 'foo' to a bin directory. I propose that it also remove ./foo (or ./foo.exe on Windows).

To respond to @dominikh, there is no need to check PWD because this only applies to 'go install' with no arguments, which always means the current directory.

Another way to view this change is that it is no different than if 'go install' (again, with no arguments) were implemented as 'go build' followed by 'mv foo $GOBIN/foo'. Using the current directory as an intermediate staging area is very common when using build tools like make. The command to install in that case is cp, not mv, but the effect is the same: the current directory never has a stale binary. This situation where you end up with a stale binary in the current directory is peculiar to the go command, and the go command can correct it.

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

Reopening because this is not yet fixed on Windows.

The code in the go command tests that FileInfo.Mode() & 0111 != 0, but on Windows FileInfo.Mode() will never have the 1 bits set.

The test on Windows is TestGoInstallCleansUpAfterGoBuild in go_test.go in http://golang.org/cl/10809. I'll skip the test on WIndows. Reenable it to test it.

Good you added new tests. :-)

Alex

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