Modern shell, process, and filesystem evidence

When the same command changes a different file

You run a familiar command in two terminals. The command text looks nearly identical and both processes return exit status 0, yet the filesystem result is different. In the first terminal the intended file changes; in the second, a same-named file in another directory changes. At the same time, a selected environment value such as DEMO_MODE changes child behavior, and a diagnostic appears on stderr that a stdout-only view would miss.

This lesson is not a shell-syntax catalog. Your output is Execution Context Trace v1: a bounded trace of the shell/runtime boundary, actual working directory, resolved executable, relevant non-secret environment, argv, stdout, stderr, exit status, and the filesystem effect you can actually prove.

The central rule is: command text is not the whole execution. If a conclusion depends on cwd, resolution, environment, streams, or file identity, make that boundary observable. The lesson does not prove application correctness across every environment, and it never treats exit status 0 as semantic correctness.

Three routes, one evidence bar

On the Foundation route, make the boundaries explicit: cwd, executable resolution, argv, selected environment, stdout, stderr, exit status, and file effect. Build one guided baseline before mutating anything. On the Repair route, return only to the first broken distinction. If you read exit status correctly but treat a relative path as a stable file identity, focus on cwd → path resolution → file hash.

On the Experienced / Fast Path, command walkthroughs are compressed, but the artifact, mutation, and residual-uncertainty requirement remain. Terminal experience is not permission to guess pwd, PATH, stream content, or file identity.

Before continuing, answer three questions: what was the process cwd, what observable discriminates the competing explanations, and what independent evidence could still reject your claim even when the process is green?

Mental model: shell context → process → streams/filesystem → bounded decision

Separate an invocation into four layers:

1. Shell/runtime context: the shell or runner, current directory, and resolution rules actually used. If you rely on Bash-specific behavior, label it Bash-specific rather than generalizing it to every shell.
2. Process inputs: the resolved executable, argv, and only the relevant non-secret environment values. A full environment dump is not automatically better evidence and can expose secrets.
3. Process observables: stdout, stderr, and exit status answer different questions. No single one proves the intended filesystem or business effect.
4. Filesystem effect: a relative path is interpreted in an execution context. output.txt is not a global identity. Record the resolved path and a before/after hash or equivalent observation.

Execution Context Trace uses those observables to make a bounded conclusion. Anything not measured stays unknown; do not promote inference into observation.

Build Execution Context Trace v1

For each run, capture at least:

• run ID and shell/runtime boundary;
• actual cwd and resolved executable;
• argv;
• whitelisted relevant environment, not a full dump;
• stdin when material to the claim;
• stdout and stderr separately;
• exit status;
• involved file paths and before/after hashes or equivalent observations;
• OBSERVED / INFERRED / UNKNOWN labels for material conclusions;
• current claim or next discriminating probe;
• residual uncertainty and a human decision.

Capture context before you change it. Repairing first can destroy the evidence needed to explain what happened.

Why exit 0 and stdout are insufficient

Exit status is an observable returned by the command/process. It answers “what status did the process return?” It does not answer “did the intended file or business behavior change?” A process can succeed while operating on a different relative path.

stdout and stderr are separate channels. Capturing only stdout leaves stderr outside your evidence. Conversely, a warning on stderr does not by itself prove semantic failure; interpret it with exit status and the actual effect.

Command lookup also has a boundary. In a Bash environment, Bash-specific tools such as command -v or type can help inspect resolution, but keep that claim bounded to Bash. At the process level, the executable path actually used by the runner is stronger evidence than a guess based on the command name.

Relative paths are a common source of terminal folklore. Two directories can both contain input.txt and output.txt. The same child program can return the same exit status while touching different file identities because cwd changed. The defensible evidence is the resolved path plus an independent file observation.

Worked example: two directories, one filename, two effects

The training fixture contains root and alternate. Both have input.txt and output.txt, but their sentinels differ. The child reads a relative input, uses whitelisted DEMO_MODE, writes a normal summary to stdout, emits a separate diagnostic to stderr, and writes output.txt in its current directory.

Run the baseline from root. The trace should show cwd resolving to root, the root output hash changing, and the alternate output staying unchanged. Reset, then run the same process-level action from alternate. Exit status may still be 0, but now the alternate output hash changes. That directly rejects “exit 0 means the intended file changed.”

A second mutation changes DEMO_MODE from safe to alternate. That changes process behavior, but it does not by itself select file identity; cwd/path resolution still does. Do not mix two variables into one explanation.

Five shortcuts to stop

“The command is the same, so the result must be the same.” Capture context and resolution; command text is only part of the input.

“Exit code zero means the task is correct.” Verify the intended effect with an independent oracle such as resolved path and file hash.

“stdout showed no problem.” Capture stderr separately and do not confuse missing evidence with evidence of absence.

“I know PATH, so I know which executable ran.” Observe resolution in that environment. Label Bash-specific probes as Bash-specific.

“output.txt is the same file.” Do not treat a relative name as identity; bind it to cwd, resolved path, and an observation.

For experienced engineers: connect the trace to real tooling without stealing later lessons

A real project may launch commands through wrappers, IDE tasks, containers, CI, or build tools. This lesson does not teach workspace managers, lockfiles, caches, or build closure; those belong to later toolchain lessons. Preserve the execution-context invariants:

• known runner/shell boundary;
• inspectable cwd and executable resolution;
• bounded argv and relevant environment;
• separate stdout/stderr/exit status;
• filesystem effect tied to real identity;
• explicit observed/inferred/unknown states;
• conclusion bounded to the evidence.

If internal tooling captures these fields automatically, Execution Context Trace can project that data. Automation standardizes collection; it does not remove the evidence requirement.

Explicit paths, relative paths, and environment inheritance without dogma

Absolute or anchored paths reduce ambiguity but can reduce relocatability. Their use alone is not correctness evidence.

Relative paths are convenient in movable repositories and fixtures, but their meaning depends on cwd. Keep cwd with the trace.

Inherited environment is convenient but creates hidden state. More explicit configuration can improve reviewability, yet dumping the full environment without need can expose secrets. Capture only relevant non-secret keys.

Shell-specific inspection may be necessary for exact diagnosis of that shell. Keep process/filesystem observations alongside it so the portability claim does not extend beyond the authority you actually have.

Lab: build the trace before repairing

Create the local fixture with the provided setup script. It needs no network, credentials, privileges, or destructive host changes. Reset is restricted to ownership-marked workspaces inside the learner package.

For the baseline, run case baseline with cwd=root and DEMO_MODE=safe. Record stdout, stderr, exit status, resolved executable, cwd, and before/after file hashes. Reset and run the same probe with cwd=alternate. If exit status remains 0 while file identity changes, preserve that as the counterexample evidence.

Then mutate DEMO_MODE and explain which observation follows the environment mutation and which follows cwd. The transfer case uses different directory names and sentinels; no ready-made command sequence is provided. Isolate one variable per probe before concluding.

Minimum defensible evidence

Execution Context Trace v1 is reviewable when material conclusions resolve to observables: shell/runtime boundary, cwd, executable path, argv, selected environment, streams, exit status, and filesystem effect. The file effect must be inspectable through path/hash evidence or an equivalent oracle.

If a field is unavailable, mark it UNKNOWN and narrow the claim. When two explanations compete, choose the smallest probe that separates them. Changing cwd and environment together is a poor discriminating probe if your goal is to determine which one caused the observed difference.

Trace acceptance remains a human decision. Machine checks can validate schema and deterministic fixture behavior, but they cannot replace the learner’s residual-risk or scope judgment.

Assessment: diagnosis, decision, application, transfer

AS1 — Diagnosis: given a run with exit 0, plausible stdout, and the wrong filesystem effect, identify the smallest failing boundary and evidence that rejects the alternative.

AS2 — Decision: judge a trace that contains stdout and exit status but lacks cwd, stderr, and file identity. Decide whether the supplied evidence is sufficient, needs a probe, or must be deferred; state residual risk.

AS3 — Application: execute the baseline and mutation, then complete Execution Context Trace v1. At least one misleading green signal must be rejected by an independent oracle.

AS4 — Transfer: reconstruct the method on a changed fixture with different cwd and environment, without a supplied command sequence. State what is observed, inferred, and still unproven.

The critical non-compensatory dimensions are context completeness, stream/process evidence separation, and filesystem identity proof. Strong prose without one of those evidence dimensions is not a full pass.

Source and freshness boundary

Current Bash behavior used here for command search/execution environment, current-directory interactions, streams/redirections, and exit status is bounded to the official GNU Bash manual. The lesson research map recorded that source on 2026-09-02 with review_due=2026-10-17; this authoring introduces no new current technical claim outside that map.

The lesson does not claim that every shell behaves like Bash. Process/filesystem observations are used only where the local fixture makes them observable. Symlink normalization, permissions, durability, concurrency, security confinement, and host-level isolation remain out of scope.

Execution Context Trace v1 is a curriculum evidence-design rule, not a mandatory standard imposed by a shell or operating system.