CC @rsc @rogpeppe @myitcv

FWIW I have extracted much of the script_test.go functionality into this package. Feel free to bring some or all of it back within the Go repository. It's missing some of the pieces that I considered were go-command-specific (particularly the bits that were about compiling Go programs, which added a reasonable amount of complexity). It should be extensible enough to add that functionality back in though.

This seems OK to try in Go 1.13 provided it stays as internal/script and we don't just grow an enormous number of "commands" in the scripting language. I don't want to commit to an API for external use. I'm also worried about, for example, the "go" command in the cmd/go tests. It doesn't make sense in a general internal/script test. What commands move? What commands stay? It's unclear to me how well this will generalize. But feel free to make a concrete proposal.

FWIW, that's the reason I removed the "go" command from my factored out version and made the set of commands extensible. I tried to keep the set of commands limited to those that were generally applicable.

Per @golang/proposal-review, accepted for 1.13.

This is essentially done — it was extracted to cmd/go/internal/script, but could easily be moved up to cmd/internal/script or internal/script with only trivial changes, if someone wants to use it elsewhere in the main repo.

The go test simplification has not been implemented yet; instead one runs something like go test cmd/go -run=TestScript/bug.txt, which doesn't seem terrible (and is easy enough to wrap with a shell script).

Postscript: you can now write compiler and linker script tests. Example here.