Think exporting a variable is optional?
In shell scripts, export is the step that actually makes a variable visible to any child process your script starts.
Without export, the assignment stays local and tools you call won’t see your settings.
You’ll get step-by-step examples, common pitfalls (spaces, PATH mistakes, sourcing vs running), and small, practical fixes so your programs read the right values.
By the end you’ll be able to export cleanly and avoid those nightly pages.
Immediate Steps to Export a Variable in a Shell Script
Inside a shell script, you use export to make a variable available to any child processes the script spawns. Without it, a variable assignment just creates something that’s visible only within the current script environment.
The syntax isn’t complicated. Assign the variable, then export it. Or do both at once. Either VAR=value followed by export VAR, or the one-liner export VAR=value gets the job done.
- Open or create your shell script. Make a file like
deploy.shand add your shebang line#!/bin/bash. - Assign the variable. Write
API_ENDPOINT="https://api.example.com"on its own line. - Export the variable. Add
export API_ENDPOINTon the next line, or combine step 2 and 3 asexport API_ENDPOINT="https://api.example.com". - Call a child command. Run any executable or script that needs the variable, like
./fetch_data.shorcurl "$API_ENDPOINT/status".
Here’s a complete working example: a deploy script that exports a build directory so a packaging tool can find artifacts.
#!/bin/bash
export BUILD_DIR="/var/builds/release-1.2.3"
export ARTIFACT_NAME="app-bundle.tar.gz"
./package.sh
When package.sh runs, it inherits BUILD_DIR and ARTIFACT_NAME from the parent script’s environment.
Understanding the Difference Between Setting and Exporting Variables
Assigning a variable with CONFIG_PATH="/etc/myapp/config.yaml" creates something that lives only in the current shell or script process. That variable doesn’t get passed to child processes unless you explicitly export it. Think of it as a local note that stays on your desk. Helpful for you, invisible to anyone you call.
Using export changes the variable’s scope. Once exported, the variable becomes part of the process environment. Any command, script, or program launched from that shell receives a copy of the exported variable in its own environment. The variable’s value doesn’t change, but where it can be seen does.
A common mistake? Assuming that exporting a variable inside a child script will push it back to the parent shell. Environment inheritance works in one direction. Parent to child. A child process can modify or extend its own environment, but those changes vanish when the child exits. Variables set and exported inside ./child_script.sh won’t appear in the shell that called it, because the child’s environment is a disposable copy.
Practical Export Examples for Real Shell Scripts
PATH modifications are probably the most common reason to export variables in shell scripts. If your script adds a custom bin directory to PATH, child commands need to see that change. Without export, the modified PATH stays local to the script, and spawned processes revert to the inherited PATH.
#!/bin/bash
export PATH="$PATH:/opt/custom/bin"
my_custom_tool --version
In this example, my_custom_tool lives in /opt/custom/bin. Exporting the updated PATH lets the shell locate and execute my_custom_tool when the script runs it.
Configuration values and runtime flags often need to be exported so external programs can read them. Take a deployment script that configures database connection strings for a migration tool.
#!/bin/bash
export DB_HOST="prod-db-01.internal"
export DB_PORT="5432"
export DB_NAME="app_production"
./run_migrations
The run_migrations binary or script reads DB_HOST, DB_PORT, and DB_NAME from the environment. Exporting these variables means the migration tool sees the correct connection parameters without requiring command-line arguments or hard-coded config files.
Variable Inheritance and Child Process Behavior
When you launch a child process, it receives a snapshot of the parent’s exported environment at the moment the child starts. Changes made by the parent after the child has already started don’t propagate backward. The child gets its own copy, and modifications inside the child stay inside that copy.
Exported variables remain visible to all descendants. If your script exports LOG_LEVEL=debug and then calls a Python script that spawns a Java process, both the Python script and the Java process can read LOG_LEVEL from their environment. The export flows down through the entire process tree.
Environment size has practical limits imposed by the operating system kernel. On Linux, the combined size of all environment variables and their values is capped, often around 128 KB or higher depending on kernel configuration. Scripts that export hundreds of large variables or extremely long strings might hit this limit, causing execve to fail with an “Argument list too long” error. In practice, typical use cases stay well below this threshold. But batch processing scripts that dynamically generate environment data should watch for size.
Troubleshooting Export Issues in Shell Scripts
Variables that don’t appear in child processes or commands that can’t find executables after PATH changes usually trace back to a handful of common errors.
Spaces around the equals sign. Writing export VAR = value introduces spaces that break the assignment syntax. Use export VAR=value with no spaces around =.
Running the script with sh instead of bash. If your script uses Bash-specific features or relies on #!/bin/bash, invoking it with sh script.sh might run it under a POSIX shell that behaves differently. Use bash script.sh or make the script executable and call it directly as ./script.sh.
Missing quotes around values with spaces. export MESSAGE=Hello World splits into multiple arguments. Use export MESSAGE="Hello World" to treat the entire string as one value.
Trying to export back to the parent shell. Executing ./setenv.sh runs the script in a child process. Exports inside it don’t affect the calling shell. To modify the current shell, source the script with source setenv.sh or . setenv.sh.
Permissions preventing script execution. If the script isn’t executable, the shell reads it as a text file rather than running it. Check with ls -l script.sh and fix with chmod +x script.sh.
Overwriting PATH entirely. Using export PATH="/new/path" replaces the entire PATH, breaking access to standard utilities. Append or prepend instead: export PATH="$PATH:/new/path" or export PATH="/new/path:$PATH".
Best Practices for Managing Environment Variables in Shell Scripts
Always quote variable values, especially when they might contain spaces, special characters, or empty strings. export CONFIG_FILE="$HOME/.config/app.conf" prevents word splitting and guarantees the variable contains exactly what you intend. Quoting is cheap insurance against parsing surprises.
Export only the variables that child processes actually need. Keeping the environment small reduces the risk of variable name collisions, limits exposure of sensitive data, and makes debugging easier. If a variable is used only for internal script logic, leave it as a shell variable.
Use a dedicated configuration file for persistent exports. Instead of embedding exports directly in every script, load them from a shared file with source /etc/myapp/env.conf or . ~/.myapp_env. Keeps configuration centralized and version controlled.
Avoid exporting secrets when possible. Environment variables are visible to all child processes and might appear in process listings or logs. For API keys and passwords, prefer secret management tools, encrypted files, or injection mechanisms provided by orchestration platforms like Kubernetes Secrets or AWS Secrets Manager.
Validate required variables early. At the top of your script, check that critical exported variables are set and non-empty. Use [ -z "$REQUIRED_VAR" ] && { echo "REQUIRED_VAR not set"; exit 1; } to catch missing configuration before the script does real work.
Prefix application-specific variables. Namespace your variables with a consistent prefix like MYAPP_ to avoid clashes with system or third-party variables. MYAPP_DB_HOST is clearer and safer than DB_HOST.
Final Words
In the action we covered the exact export forms (VAR=value; export VAR or export VAR=value), when to use them, and a quick 4-step cheat to run exports reliably.
You saw the difference between shell-local and exported variables, how child processes inherit environment, PATH and config examples, and a short troubleshooting checklist for common mistakes like wrong shell or spaces around =.
Keep values quoted, avoid unnecessary exports, and test scripts—exporting environment variables in shell scripts is a small habit that prevents a lot of late-night debugging.
FAQ
Q: How do I export a variable in a shell script?
A: Exporting a variable in a shell script means assigning it then marking it exported, for example: VAR=value; export VAR or export VAR=value, so child processes inherit the variable.
Q: What’s the correct syntax to set and export a variable?
A: The correct syntax is either VAR=value then export VAR, or export VAR=value; both make the variable part of the environment passed to child processes.
Q: What’s the difference between setting a variable and exporting it?
A: Setting a variable creates a shell-local value; exporting a variable adds it to the environment so child processes can see it. Export changes scope, not the variable’s value.
Q: Will exporting a variable change the parent shell?
A: Exporting a variable does not change the parent shell; exported values only go to child processes. To affect the parent, source the script (for example: . ./script) so it runs in that shell.
Q: How do I export PATH or sensitive values like API keys safely?
A: Exporting PATH requires updating then exporting it, e.g., PATH=/new:$PATH; export PATH. For API keys, export only when needed and prefer config files or secret stores instead of hardcoding in scripts.
Q: Why isn’t my variable exporting from a script?
A: Variables often fail to export because the script was executed instead of sourced, the wrong shell was used (sh vs bash), there are spaces around =, missing quotes, or the variable is set after child processes start.
Q: What are best practices for managing environment variables in scripts?
A: Best practices include quoting values, avoiding unnecessary exports, using config or secret stores, keeping sensitive data out of repos, limiting scope, and documenting required variables for each script.