I've implemented this a couple of times myself, so I'd like to see it in os/exec too.

As a bonus we could shell-quote args as needed for clarity. But too far down that path lies madness. The intent is human readable output only. We’d document that.

I've often wanted this as well.

But I've also often extended such a string to be prefixed by the environment variables I added atop os.Environ(), so the resulting string becomes something like:

GOBIN=/some/path GOPROXY= go install example.com/blah

This is clearly not an argument against String() as proposed, but more a question on how often it would end up being useful.

@myitcv I have done that in the past, in places where I knew cmd.Env was a superset of os.Environ(). But I don't know how it could be generalized, since cmd.Env can contain arbitrary values, and if cmd.Env is not a superset of os.Environ, then printing them all might be a little too chatty. If exec.Cmd implemented fmt.Formatter, perhaps the extra environment variables could be added to the string if %+v is specified, or something. But this whole thing feels a little beyond the scope of the current issue.

But this whole thing feels a little beyond the scope of the current issue.

Totally. Just to confirm, I was not advocating broadening the scope, just raising the question.

ISTM that this is still useful: you’d print the appropriate env vars and then use String to print the rest. But perhaps I misunderstand the question.

Accepted per @golang/proposal-review .

Change https://golang.org/cl/168518 mentions this issue: os/exec: add Cmd.String