010-100 · Question #89
What is the purpose of the bash built-in export command?
The correct answer is D. To setup environment variables for applications. The bash built-in export command marks shell variables so they are inherited as environment variables by child processes and sub-shells.
Question
What is the purpose of the bash built-in export command?
Options
- ATo allow disks to be mounted remotely.
- BTo run a command as a process in a sub-shell.
- CTo make the command history available to sub-shells.
- DTo setup environment variables for applications.
- ETo share NFS partitions for use by other systems on the network.
How the community answered
(62 responses)- A6% (4)
- B5% (3)
- C2% (1)
- D71% (44)
- E16% (10)
Why each option
The bash built-in export command marks shell variables so they are inherited as environment variables by child processes and sub-shells.
Remote disk mounting is handled by the mount command combined with NFS or CIFS configuration, not by the bash export built-in.
Running a command in a sub-shell is done using parentheses (cmd) or bash -c 'cmd', not export.
Command history availability is managed via the HISTFILE variable and the history built-in; export does not control history sharing.
When a variable is declared in a shell without export, it exists only in that shell's scope. Using export promotes the variable to an environment variable, meaning any sub-shell or child process spawned afterward will inherit it. This is the standard mechanism for passing configuration such as PATH, JAVA_HOME, or custom app settings to programs.
Sharing NFS partitions is configured through /etc/exports and the exportfs utility, which are entirely separate from the bash export built-in.
Concept tested: bash export built-in and environment variables
Source: https://www.gnu.org/software/bash/manual/bash.html#index-export
Topics
Community Discussion
5The answer is D, and here is the sticky way to lock it in: think EXPORT = "EXtend PORTal To children." When you export a variable in bash, you are stamping it with a passport so that any child process or sub-shell spawned after that point can read it as part of its environment. Without export, a variable you set stays trapped in the parent shell like a secret in a locked room, invisible to every program or script you launch from there. Options A and E are NFS/network territory (think filesystem, not shell), B describes a sub-shell execution trick like bash -c, and C is about history which lives in HISTFILE, not export at all.
The mnemonic is clever but watch out: "child process" and "sub-shell" are not the same thing, because a sub-shell like (cmd) inherits variables even without export, while a true child process (a separate executable) does not, and that distinction is exactly what makes exam questions on this topic tricky.
I actually saw this one on my practice run last week and almost picked B because I kept thinking "export sends something out, like a subprocess," but then I remembered when we set PATH in class and it clicked that export is how you push a variable into the environment so child processes can actually see it, which is D.
The qualifier to watch here is "built-in" and "export" specifically, so do not let A and E distract you with the NFS and disk-mounting language, those are network filesystem concepts that belong to commands like exportfs, not the bash built-in. B is close in spirit because sub-shells are involved, but the export command does not run anything, it marks variables so child processes can inherit them as environment variables. C is the sneaky wrong answer because history is a separate bash concept entirely, export has nothing to do with it. D is correct. When you type something like export MY_VAR=hello in bash, you are flagging that variable so any sub-shell or child process spawned afterward will see it in its environment, which is exactly how PATH, HOME, and similar variables get passed down to programs you launch.
One thing I kept tripping on is that the variable only travels down to child processes started after you run export, so if you want it to survive closing the terminal you still have to drop it into something like .bashrc.