Questions: Command-Line Arguments and Environment Variables

Question 1

A shell script contains the line: export DATABASE_URL=postgres://localhost/mydb. After the script finishes, you check the variable in your interactive shell and find it is not set. What explains this?

• A. The export keyword only sets variables for the script's own use, not for child processes
• B. The script ran in a child process; environment changes in child processes do not propagate to the parent
• C. The variable was set incorrectly — DATABASE_URL cannot contain slashes
• D. Environment variables set in scripts are automatically unset when the script exits

Answer: (B)

When a shell executes a script normally (./script.sh), it creates a child process to run it. That child inherits the parent's environment and can modify its own copy freely — but those modifications die with the child process. The parent never sees them. Environment inheritance flows downward (parent → child), never upward. To make the script's changes affect the current shell, you must *source* it (. script.sh or source script.sh), which runs the commands in the current shell process rather than a child.

Question 2

What is the difference between running ./configure.sh and source ./configure.sh with respect to environment variables?

• A. source runs the script faster because it skips process creation overhead
• B. source executes the script's commands in the current shell process, so any environment changes persist in the calling shell; ./configure.sh runs in a child process where changes are invisible to the parent
• C. There is no difference — both methods inherit the parent environment and return it after completion
• D. source prevents the script from accessing the parent shell's environment variables for security reasons

Answer: (B)

Sourcing a script (. script.sh or source script.sh) is fundamentally different from executing it: sourcing runs the commands directly in the current shell's process, so variable assignments, exports, and directory changes all affect the current shell's state. Executing (./script.sh) creates a new child process, which gets a copy of the environment — changes to that copy vanish when the child exits. This distinction is why .bashrc, .profile, and Python virtualenv activation scripts must be sourced, not executed.

Question 3

Environment variable changes made by a child process are not visible to the parent process that launched it.

• T. True
• F. False

Answer: True

This is a fundamental property of Unix process model: environment variable changes propagate downward through fork/exec (parent → child) but never upward. When a child calls setenv() or putenv(), it modifies only its own in-memory copy of the environment. The parent's copy is unchanged. This isolation is intentional — it prevents child processes from inadvertently (or maliciously) modifying the environment of the process that launched them.

Question 4

When a shell expands wildcards like *.txt before passing arguments to a program, the program receives the original *.txt pattern and performs its own expansion internally.

• T. True
• F. False

Answer: False

Shell expansion happens *before* the program starts, in the shell process. By the time the target program's main() function is called, argv already contains the expanded filenames — the program never sees *.txt. This is why the same program behaves differently when called from different shells: the shell, not the program, controls what argv contains. It also means a program cannot distinguish between `cp *.txt dest/` (wildcard expanded by shell) and `cp file1.txt file2.txt dest/` (explicit filenames) — both arrive in argv as individual filenames.

Question 5

Why do command-line arguments and environment variables serve complementary rather than identical purposes, and when is each appropriate?

Model answer: Command-line arguments communicate what a process should do *in this specific invocation* — they are transient, per-run instructions. Environment variables communicate the context the process is running in — they are persistent configuration that is inherited by all child processes. Arguments are appropriate for things that change between invocations (which files to process, which operation to perform); environment variables are appropriate for things that stay constant across many invocations (the user's home directory, the search path for executables, the preferred language). Because arguments are not inherited, they cannot propagate configuration down a process hierarchy; environment variables can.

The distinction maps to function parameters vs. global state in programming. Arguments are like parameters — explicit, local, per-call. Environment variables are like a configured global context — implicit, inherited, session-wide. Mixing up these roles (e.g., passing PATH as a command-line argument to every program) would be impractical; the inheritance model is what makes environment variables useful for system-wide configuration.