-
Notifications
You must be signed in to change notification settings - Fork 81
Description
At https://github.com/cue-lang/cue we use test scripts for our integration tests, as well as for users providing reproducers for bugs.
There's one unfortunate inconsistency: the former use cue
, and the latter use exec cue
.
I initially thought that we should use cue
everywhere, by adding a new flag to cmd/testscript
like -x cue
, so that a command "passes through" to executing a program from $PATH
. Then, we would use cue
everywhere rather than exec cue
. However, then bug report reproducers aren't truly standalone, as one needs to remember to use the flag.
@rogpeppe suggests that we should use exec cue
everywhere instead. This already works in today's testscript.RunMain
, as top-level commands are put in a temporary directory and appended to $PATH
. We simply prefer cue
rather than exec cue
since we're used to how it was before, where exec cue
might fail to find the program if one hadn't run go install
first, as we wouldn't fix up $PATH
.
I think Roger's idea is better. It's slightly more verbose, but:
- It's consistent everywhere - tests and standalone reproducers.
- It keeps
exec
explicit, which is a good thing given that it's special. It usesstdin
, setsstdout
andstderr
, runs as a separate process, can be run in the background, etc.