The setting is visible in the shell but missing from the program
A maintainer can follow an instruction, display the expected value and still start a program without the configuration it needs. The question is not only whether a setting exists, but whether the process performing the task receives it.
This fictional handover concerns a small report-checking command used before a staff workpack is prepared. The example uses an isolated fixture directory containing invented records. It involves no credentials, production files or external services.
Reproduce the recipient's ordinary attempt
The instructions tell the successor to set REPORT_ROOT to the fixture directory and then run the checker. The successor assigns the variable in a Bash shell and displays it. The printed path is correct, and the expected fixture file exists there.
The checker is an external program. It reads REPORT_ROOT from its process environment and stops with “Report directory not configured.” The source data has not disappeared; the receiving process has no value for the required setting.
The developer's earlier demonstration used a shell in which REPORT_ROOT had already been marked for export. The supplied instructions omitted that distinction. Copying the same visible assignment into a fresh shell does not recreate the developer's environment.
Inspect the process boundary
An ordinary shell variable and an exported environment variable are not interchangeable for an external command. Bash passes variables marked for export, along with command-specific environment assignments, into subsequently executed commands.
The Bash manual's environment section explains this distinction. It also distinguishes the environment of an external command from other shell behaviour. A built-in display command seeing a shell value does not prove an external checker will receive it.
The useful evidence in the fixture is therefore:
| Observation | Result before correction |
|---|---|
Display REPORT_ROOT in the parent shell |
Intended fixture path is present |
| Check the expected file at that path | Fixture report R-73 exists |
| Inspect the checker's own required-variable lookup | REPORT_ROOT is absent |
| Run the checker | It stops before processing a report |
The missing export is established without moving the files, changing the working directory or granting broader access. Those would be different changes with no evidence that they address this failure.
Make the command's configuration explicit
The corrected handover uses an explicit environment assignment for the checker invocation. That provides REPORT_ROOT to that command for its execution without relying on a setting left behind in an earlier interactive session.
The actual documented invocation names the approved fixture location and the checker. The maintainer does not repurpose a general system variable or print the complete environment to discover the value. Only the non-sensitive setting needed for this task is inspected.
An explicit export in the intended launcher could also be appropriate for another operating arrangement. The selected correction here is the command-specific assignment, and the instructions use that one approach consistently. A scheduled service would need its own supported configuration mechanism rather than an assumption that it inherits an interactive shell.
Have the successor finish the same task
The successor starts with a fresh shell and uses the corrected instruction. The checker receives the intended directory, opens R-73 and reports its fixture record identifier. The file's contents and digest are unchanged. The command has received configuration; it has not generated a replacement report.
The review also records the working directory before and after the correction. It remains the same. That control separates the environment-variable cause from a relative-path problem.
An unrelated optional setting retains its prior value. A second report R-74 in the same approved fixture directory remains readable. When REPORT_ROOT is deliberately omitted in a separate control, the checker still refuses to proceed with a clear missing-configuration message; it does not fall back to an unrelated directory.
The successor can now explain why the earlier display was insufficient and reproduce the corrected operation without the original developer's shell session. That is the completed handover result.
Keep the failure boundary useful
A program that silently chooses another directory after a missing setting could conceal the defect. The review should establish whether an explicit stop is required when the configuration is absent or invalid. A default is appropriate only when the operating contract actually defines one.
Do not extend this fixture into a claim about the entire deployment. Network access, permissions, dependencies and operational data may require separate checks. The isolated example establishes that this required setting reaches this external process and that the intended file is used.
The final instructions identify the launcher, required setting, expected report evidence and stopping condition. They also state where the arrangement differs for an interactive command, a scheduled task or a managed service.
Use support planning to choose the operations the recipient needs to rehearse. If an inherited application's instructions work only for their original author, application repair can investigate the missing dependency before a larger replacement is considered.