If GOBIN is previously set in env, clean.bash uses the env value.

Because bash {param:-default} only set a value when the parameter is unset or null.

The following change will resolve the issue:

-gobin="${GOBIN:-../bin}"
+gobin="${GOROOT}"/bin

Change https://golang.org/cl/215478 mentions this issue: build: set GOBIN during clean

@nikson I think using GOROOT is wrong.

What happens if in $GOROOT (/usr/lib/go on my Linux distribution) there is go 1.13.x and I'm trying to build go 1.20.x?

clean.bash (and probably also clean.rc) should use the newly built go binary.

@perillo clean.bash sets $GOROOT to the src root, thus the proposed change will use the newly built binaries.

@nikson, you are right sorry. I was assuming that make.bash would move the binaries to $GOROOT_FINAL. I forgot that it just hardcode the GOROOT into the binaries.

The GOBIN variable seems like a red herring: as far as I am aware, it does not affect the install directory for binaries built from GOROOT (including cmd/go).

~$ GOBIN=/tmp go1.12.14 list -f '{{.Target}}' cmd/go
/usr/local/google/home/bcmills/sdk/go1.12.14/bin/go

~$ GOBIN=/tmp go1.14beta1 list -f '{{.Target}}' cmd/go
/usr/local/google/home/bcmills/sdk/go1.14beta1/bin/go

~$ GOBIN=/tmp go list -f '{{.Target}}' cmd/go
/usr/local/google/home/bcmills/go/bin/go

The real problem here, I think, is that clean.bash should not care about GOBIN at all, and today it does.

CC @matloob @jayconrod

A git log --grep=GOBIN -p make.bash reported some interesting informations.

As an example, from https://codereview.appspot.com/2043041, and in detail, from
https://codereview.appspot.com/2043041/patch/8001/9009
it seems that the early build system used some tool that where copied to GOBIN (maybe from an early phase in the build?).

Bash scripts either unset GOBIN or use GOROOT/bin when required. We're now using the GOROOT/bin path explicitly in the clean.bash, thus avoiding GOBIN.

go/src$ grep GOBIN *.bash
iostest.bash:unset GOBIN
make.bash:unset GOBIN # Issue 14340
run.bash:export GOBIN=$GOROOT/bin  # Issue 14340

I've sent another revision with the updated commit message.

As a 10 year Go user I was just bitten by NOT having GOBIN work as expected. Let me ask a related question.

Is it a goal (still a goal) that a single GOROOT support multiple GOOS and GOARCH combinations?

I always assumed it does because tools go in ${GOROOT}/pkg/tools/${GOOS}_${GOARCH} and you used to be able to control where the commands were installed with GOBIN. So putting the commands in ${GOROOT}/bin/${GOOS}_${GOARCH} would be consistent with how the tools are installed. I don't understand why the tools are installed a different way than the commands.

Let me explain the environment I am trying to set up. I want to have a single set of directory pairs that define my go environment. One directory for ${GOROOT} and one for ${GOPATH}.

In one case I use these directories locally on my Mac to compile and deploy on Mac ("darwin_amd64"). In another case I mount these directories in a Docker linux container and deploy on Linux ("linux_amd64)". Everything is in sync. Same version of go, same tools, same source code and packages. Everything is self contained. That last statement is worth something right?

By not supporting GOBIN, which was supported for a long time, the decision has effectively been made to eliminate support for multiple multiple GOOS and GOARCH combinations in a single GOROOT and something has been lost.

My proposal is as follows:
Remove support for GOBIN. It is already not supported (unset in make.bash) but that isn't documented, correct? Install commands in ${GOROOT}/bin/${GOOS}_${GOARCH}. That allows support for multiple GOOS and GOARCH in a single GOROOT and it is consistent with the way the tools are installed.