While writing a test for #29253, it is apparent that using the existing cmd/go script test framework makes the test writing easy and straightforward. However, I don't like the fact that a test for cmd/link has to be placed in cmd/go/testdata/script.

I think the underlying concept of the script is very useful and enables us to write very simple single file test cases for even the most complicated scenarios.

I'd like to suggest that we move its functionality to internal/script (and txtar) and also make it client extendable so that it's possible for all cmd/* packages to use it (perhaps we can even unify the $GOROOT/test/run.go with it?)

Also, I'd like to make it possible to run single text archive go test cases with something like:

   go test internal/script bug.txt

Perhaps we could even make a go report-bug command to automate the packaging of such test cases? (Then we don't need to create a repo just to show a Go bug, and I think a lot of other products support a way to bundle a test case into a single file, the text archive is quite useful in this context.)

Thoughts?

Comment From: bcmills

CC @rsc @rogpeppe @myitcv

Comment From: rogpeppe

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.

Comment From: rsc

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.

Comment From: rogpeppe

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.

Comment From: andybons

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

Comment From: bcmills

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).

Comment From: thanm

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