What does setting exec.Cmd.Env do to a Go child process, and which PATH resolves the binary?

## `Cmd.Env` replaces; it never merges The field is documented as the environment of the process: "If Env is nil, the new process uses the current process's environment." The word to notice is *uses*, not *adds to*. Once you assign a non-nil slice, that slice **is** the environment. ```go cmd := exec.Command(bin, "apply") cmd.Env = []string{"DEPLOY_ENV=staging"} ``` That child runs with exactly one variable. No `PATH` (so any program *it* launches by bare name will fail), no `HOME` (so tools that read a config file from the home directory silently fall back to defaults), no `TZ`, no proxy settings, no terminal type. The failure this produces is nearly always confusing, because the tool works perfectly when a human runs it. Two correct patterns: ```go cmd.Env = append(os.Environ(), "DEPLOY_ENV=staging") // inherit, then add cmd.Env = append(cmd.Environ(), "DEPLOY_ENV=staging") // same, via the Cmd ``` `Cmd.Environ()` returns the environment the command *would* run with, which is the parent's set when `Env` is nil, adjusted for `Dir`. Building on it keeps you consistent with whatever else you have already configured. ### Duplicates: last wins The slice is a plain `[]string` of `KEY=VALUE` entries and nothing deduplicates it. If the same key appears twice, the later entry is the effective one. That is exactly what makes the `append` idiom work — you are appending an override after the inherited copy — and it is also why you should not assume the slice you built is minimal. ### Deliberately minimal environments Sometimes an empty-ish environment is what you want: reproducible builds, or a step that must not see a token in the parent's environment. Do it consciously and carry over what the tool actually needs — typically `PATH`, `HOME` and `TZ` — rather than discovering the list one incident at a time. ## `Cmd.Dir` `Dir` is the working directory the child starts in; empty means the calling process's current directory. Setting it is strongly preferable to calling `os.Chdir` in your own program, because the working directory is process-wide state and a concurrent goroutine launching another command would see it change underneath. One subtlety: if `Cmd.Path` is a **relative** path, it is evaluated relative to `Dir`. So `exec.Command("./tool")` with `cmd.Dir = "/opt/pkg"` runs `/opt/pkg/tool`, not a `tool` in your own directory. ## Which `PATH` finds the program This is the part that surprises people. `exec.Command(name, ...)` resolves `name` **at construction time**, before you have had a chance to set any field: - If `name` contains a path separator, it is used as-is (and, if relative, resolved against `Dir` as described above). - Otherwise `exec.LookPath(name)` searches the `PATH` of the **calling** process — the value in your own environment right now. So `cmd.Env = append(os.Environ(), "PATH=/opt/pinned/bin")` does *not* change which binary runs. It changes the `PATH` the child sees, which affects programs *it* launches, but the file already chosen for `Cmd.Path` was picked from your `PATH`. If you want a specific build, do the resolution explicitly: ```go bin, err := exec.LookPath("deployctl") // fail fast, with a clear message if err != nil { return fmt.Errorf("deployctl not installed: %w", err) } cmd := exec.Command(bin, "apply") ``` or set `os.Setenv("PATH", ...)` in the parent before constructing the `Cmd`, or simply pass an absolute path. `exec.LookPath` also declines to resolve a program through a relative entry in `PATH` such as `.` or an empty element. It returns `exec.ErrDot` instead, so a program in the current directory is not silently preferred over one on the system path; if you really mean the local file, name it `./tool`. ## Failing fast Because `exec.Command` stashes the lookup failure in `Cmd.Err` rather than returning it, a missing binary does not surface until you run the command — often deep inside a workflow, after other steps have already changed state. A program that shells out to tools it does not own is better off resolving every one of them with `exec.LookPath` at startup and refusing to begin, with a message naming the tool, than discovering a `PATH` problem halfway through.