Which command is used to make a shell variable known to subsequently executed programs?

Prof. SaraJun 16, 2026

The answer is A, export. The export built-in marks a shell variable for inclusion in the environment of any child process spawned from that shell, which is exactly what "making it known to subsequently executed programs" means in POSIX shell terminology.

Mateus R.Jun 26, 2026

Think of a shell variable like a note you wrote on your personal desk pad, only you can see it, but the moment you "export" it, you pin a copy on the bulletin board in the hallway so any program that walks by can read it. So ask yourself: when you run a child process from your shell, does it inherit variables from your private pad or from that hallway bulletin board?

Yusuf A.Jun 2, 2026

The senior tech I shadow always drills me on this one because env trips people up. You can run env to see your current environment variables or even set one for a single command like env VAR=value ./script.sh, but that does not make a variable persist into child processes the way export does. export is the bash built-in that marks a variable for inheritance by subprocesses, so when you run export MYVAR=hello and then launch a new program, that program can read MYVAR from its environment. mv is for moving files and announce and transfer are not real commands, so the answer is A.

Mei-Ling H.Jun 26, 2026

export is the right pick here. The question says "known to subsequently executed programs," which is the definition of making a variable part of the environment that child processes inherit, so B, D, and E are not real shell commands for this purpose, and C (env) can display or temporarily set environment variables but is not the command you use to mark a variable for export from the current shell. My question is: if you already ran "env VAR=value somecommand," does that count as "exporting" the variable to the child, or does the exam consider export the only correct way to pass a variable down to child processes?