A bash script sets GREETING=hello and then runs ./child.sh, but child.sh prints an empty value for $GREETING. Why doesn't the child see it, and what makes a variable visible to child processes?

## Two different stores A bash process holds a table of **shell variables**: every name you assign to, plus the ones bash maintains itself. It also holds an **environment**, which is a plain list of `NAME=value` strings. When bash starts a program, the environment — not the shell-variable table — is what gets passed to that new process. A variable joins the environment only if it carries the *export attribute*. This is why the two look identical inside one script and diverge the moment another process is involved: ```bash GREETING=hello # shell variable, no export attribute echo "$GREETING" # hello — same shell, so of course it works bash -c 'echo "[$GREETING]"' # [] — a different process, empty ``` ## What export actually does `export GREETING` does not copy a value anywhere. It flips a flag on the name. From then on, whenever bash launches an external command, it builds that command's environment from every variable currently carrying the flag. `export GREETING=hello` is just the assignment and the flag in one statement. `declare -x GREETING` is the same thing spelled differently. The flag can be removed with `export -n GREETING`, which keeps the value as an ordinary shell variable but stops passing it on. `unset GREETING` removes the variable entirely. To see what is currently exported, use `export -p` or `declare -x` (both print exported names with their values) or `printenv` / `env` (both print the raw environment). Plain `set` prints *all* shell variables and functions, exported or not — which is why `set | grep GREETING` will happily show you a variable the child will never receive. ## The copy is one-way and per-launch Each child gets its own snapshot, taken at launch time: - Changes the parent makes **after** the child started do not reach the running child. There is no shared memory here, just a copy handed over at process creation. - Changes the child makes never travel back up. A script cannot export a variable into the shell that ran it. This is why tools that need to set variables in your shell tell you to `source` them, or to run something like `eval "$(tool env)"`, rather than just executing them. That one-way rule is the single most common source of confusion. "I set it in the sub-script and the parent still shows the old value" is not a bug; it is process isolation working as designed. ## The one-shot form Putting assignments in front of a command builds a temporary environment for that command only: ```bash GREETING=hello ./child.sh # child.sh sees GREETING=hello echo "${GREETING-unset}" # unset — the shell's own table was not touched ``` This is the right tool when you want to influence one invocation — a locale for one `sort`, a timezone for one `date` — without leaking the setting into the rest of the script. ## Where it bites in real scripts - **A variable set before a tool runs, but not exported.** `API_TOKEN=abc` then `curl` — curl reads its own environment, sees nothing, and you get a 401 that looks like a credential problem. - **Assuming `set -a` is on.** `set -a` (allexport) marks *every* subsequent assignment for export, which is how `set -a; . ./config.env; set +a` turns a plain `KEY=value` file into environment for children. Without it, sourcing that file only populates shell variables. - **Expecting a child to write back.** A wrapper script that computes a value and assigns it cannot hand that value to its caller through a variable; it has to print it, and the caller has to capture the output. - **Exporting too much.** Everything exported is visible in the child's `/proc/<pid>/environ` and in `ps -e` output on some systems, and it is inherited by *every* descendant. Secrets carried this way spread further than people expect. ## Quick diagnosis When a child is not seeing a value, check which side is missing it. `printenv NAME` inside the parent tells you whether it is in the environment at all; `declare -p NAME` shows the value and the attributes, where a leading `declare -x` confirms the export flag is set.