Skip to content

suggest using exec foo for top-level commands rather than foo for consistency #163

@mvdan

Description

@mvdan

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:

  1. It's consistent everywhere - tests and standalone reproducers.
  2. It keeps exec explicit, which is a good thing given that it's special. It uses stdin, sets stdout and stderr, runs as a separate process, can be run in the background, etc.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions