-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
suggest using exec foo
for top-level commands rather than foo
for consistency
#163
Comments
Also: we should add a boolean flag like |
You've won me over 😄 |
mvdan
added a commit
to mvdan/go-internal
that referenced
this issue
Jun 28, 2022
We also document how top-level commands fed to RunMain work with and without "exec" the same way, and how RequireExplicitExec can drop backwards compatibility for greater consistency. Fixes rogpeppe#163.
mvdan
added a commit
to mvdan/go-internal
that referenced
this issue
Jun 28, 2022
We also document how top-level commands fed to RunMain work with and without "exec" the same way, and how RequireExplicitExec can drop backwards compatibility for greater consistency. Fixes rogpeppe#163.
mvdan
added a commit
to mvdan/go-internal
that referenced
this issue
Jul 6, 2022
We also document how top-level commands fed to RunMain work with and without "exec" the same way, and how RequireExplicitExec can drop backwards compatibility for greater consistency. Fixes rogpeppe#163.
mvdan
added a commit
that referenced
this issue
Jul 6, 2022
We also document how top-level commands fed to RunMain work with and without "exec" the same way, and how RequireExplicitExec can drop backwards compatibility for greater consistency. Fixes #163.
porcuepine
pushed a commit
to cue-unity/unity
that referenced
this issue
Aug 17, 2022
Use `exec git` and `exec unity` instead. This removes the need for any setup at all, but is also a better solution as `exec` can show stdout and stderr. Moreover, we are moving testscript towards using `exec` consistently; see rogpeppe/go-internal#163. Signed-off-by: Daniel Martí <mvdan@mvdan.cc> Change-Id: I69edd03efc0f3cf5ca6c32f4c71783ebb9524ae4 Reviewed-on: https://review.gerrithub.io/c/cue-unity/unity/+/541992 TryBot-Result: <cue.porcuepine@gmail.com> Reviewed-by: Paul Jolly <paul@myitcv.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 useexec cue
.I initially thought that we should use
cue
everywhere, by adding a new flag tocmd/testscript
like-x cue
, so that a command "passes through" to executing a program from$PATH
. Then, we would usecue
everywhere rather thanexec 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'stestscript.RunMain
, as top-level commands are put in a temporary directory and appended to$PATH
. We simply prefercue
rather thanexec cue
since we're used to how it was before, whereexec cue
might fail to find the program if one hadn't rungo install
first, as we wouldn't fix up$PATH
.I think Roger's idea is better. It's slightly more verbose, but:
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.The text was updated successfully, but these errors were encountered: