cmd/go: add -C flag to change directory

[thockin]

I'm not sure if this rises to a proposal or not.

Many tools (e.g. make, git) have a universal -C <dir> flag which lets you do things in other directories without pushd/popd silliness. Given how go uses CWD for important things like modules, it would be nice to have something like this in go. For example go -C path/to/dir list gives me the package-path. Otherwise it's things like pushd path/to/dir >/dev/null; go list; popd >/dev/null.

It's really just a convenience thing. Has it already been discussed? I couldn't find it.

[mvdan]

I imagine this would be a flag to follow go <cmd>, such as go build -C dir or go test -C dir ./.... I don't think the root go command has ever taken flags directly, so it would be odd to break that rule - unless we deem this flag special enough. Note that we already have common flags between some commands, such as -modfile or -x. I also imagine some commands may not need this flag, such as go version or go bug, but perhaps I'm wrong.

As for the logic itself: would it effectively replace the use of the current directory everywhere? For example, if I do go build -C /new/dir -o cmdbin foo.com/cmd@latest, would the binary show up in /new/dir/cmdbin or in ${PWD}/cmdbin? I would imagine the former for the sake of consistency; just like what a real pushd/popd pair would do. Note there are plenty of other flags that accept relative paths, such as -modfile or -overlay, so we need to think about them all together.

I think I'm neutral on this proposal. On one hand, it seems like a harmless addition, and there is indeed precedent in other popular tools. On the other hand, it's hard to judge how necessary the flag really is, and it does seem like a pretty far-reaching flag compared to the other common flags we have right now.

What particular use case are you thinking about? What is the particular problem with pushd/popd, the verbosity of it?

[thockin]

I imagine it would be a very straightforward implementation. If the flag is set, chdir() and carry on as before. No further semantic changes. I ack the notion that the bare go command doesn't take flags, but I would argue this sort of flag makes the most sense as a universal modifier. If not, I would then argue that most sub-commands should have it. Happy to audit those individually. The main use case is to avoid the constant refrain of `pushd path/to/foo

/dev/null; to do whatever; popd >/dev/null` in scripts (even worse if I

need the exit code from go) and to make it more like the other tools. It's totally a convenience and convention thing, but also pretty trivial to implement (I hope).

…

Message ID: ***@***.***>

[zikaeroh]

The main use case is to avoid the constant refrain of pushd path/to/foo >/dev/null; to do whatever; popd >/dev/null in scripts (even worse if I need the exit code from go) and to make it more like the other tools.

You could use a subshell, which is a lot shorter than pushd/popd (or even the quietier cd foo; cd -) and do give you back the exit codes.

$ (cd foo; pwd; true); echo $?
foo
0
$ (cd foo; pwd; false); echo $?
foo
1

I most commonly do this with my Go checkout to run make.bash from my repo root: (cd src; GOGC=off ./make.bash).

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

If -C is really "do a chdir before anything else", then that's easy. But what about

go build -C bar -o x.exe 

or worse

go build -o x.exe -C bar

Does that x.exe get written to bar/x.exe? What behavior will people expect?

It sounds like the suggestion here is that this command writes to bar/x.exe.
Will that be too confusing for people?

/cc @matloob @bcmills

[thockin]

I think bar/x.exe is consistent with other tools' semantics.

…

On Wed, Jan 19, 2022 at 10:18 AM Russ Cox ***@***.***> wrote: If -C is really "do a chdir before anything else", then that's easy. But what about go build -C bar -o x.exe or worse go build -o x.exe -C bar Does that x.exe get written to bar/x.exe? What behavior will people expect? It sounds like the suggestion here is that this command writes to bar/x.exe. Will that be too confusing for people? /cc @matloob <https://github.com/matloob> @bcmills <https://github.com/bcmills> — Reply to this email directly, view it on GitHub <#50332 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKWAVFJWLCREK54BOTWD6TUW357PANCNFSM5KVXFUMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[rsc]

@matloob @bcmills, any thoughts on adding -C meaning exactly

go cmd -C dir ...
==
(cd dir && go cmd ...)

where the parens make the shell switch back when go exits.

?

[fsouza]

Being nitpicky here, but I assume we'd want to make it equivalent to (cd dir && go cmd ...)? like if dir doesn't exist, go should bail with a non-0 code.

[mmwtsn]

This would be a nice, small change that is consistent with other tools like git and would help simplify build scripts.

I worked on some build automation last year on a previous team that had most of their code in a monorepo. All of the build instructions and scripts were littered with pushd/popd or the equivalent cd dir && go … && cd .. pattern. This added a bit of visual noise and in some cases was error-prone when directory structures were refactored as the relative paths in cd .. needed updating. In those same scripts, git repositories outside of the main monorepo were interacted with using git -C.

I've seen some Makefiles in Go projects that followed patterns similar to this that would have also benefitted:

GOCMD=go
GOBUILD=$(GOCMD) build
BINARY_NAME=app

build: 
  cd dir; $(GOBUILD) -o $(BINARY_NAME) -v

The directory traversal was typically handled with something like that or $(MAKE) -C dir but having the Go tooling handle the directory change without needing to worry about using a subshell or invoking Make is a little easier to work with. For both shell scripts and Makefiles, I often see counter arguments raised that "you could just do x!" which are often technically correct but less friendly to developers who may not be as familiar with some rough edges in both areas. In that sense, a go -C flag would likely be easier to use for a wider range of backgrounds and experience levels, which I think is a good thing.

[rsc]

Any objections to adding this?

[dmitshur]

I tried to think of whether any existing cmd/go behaviors might intersect poorly with this, and did not spot a glaring serious conflict.

For example, go build takes -modfile that allows selecting an alternative go.mod file, which is okay to do at the same time as using another working directory.

Presumably, it'd also be possible to set -C via cmd/go's GOFLAGS environment variable, possibly configured in environment or via go env -w. Since the go command doesn't use the current working directory while looking up go env GOENV, it doesn't conflict.

Edit: Also, go test and go doc have boolean -c (lower case) flags. They do not conflict since this proposal is about -C (upper case).

[mmwtsn]

I'd be interested in working on this if there are no objections to the proposal and no one else has picked it up yet.