How to Use the export Command in Bash

If you’ve ever poked around in a Linux or macOS terminal, you’ve almost certainly seen the export command used in tutorials, shell scripts, or even in your own .bashrc or .profile file. It’s one of those commands that seems to pop up everywhere, yet it’s rarely explained in detail unless you go hunting for answers.

But what exactly does export do? Why do you sometimes need it, and what happens if you forget it? If you’ve ever set a variable in Bash and wondered why it wasn’t available to your script or child process, you’ve run into the very issue export solves.

Let’s take a deep dive into export-how it works, when to use it, and how it fits into the bigger picture of shell variables and environment management. We’ll also cover best practices, common mistakes, and some advanced techniques that can save you time and headaches.

The Basics: What Is export?

At its core, the export command in Bash is how you make shell variables (which are local to your shell session by default) available to child processes. When you “export” a variable, you’re promoting it from a regular shell variable to an environment variable.

Think of environment variables as a way to pass information from your shell to any program or script that you run. This is a foundational part of how Unix-like systems work-environment variables are used for everything from specifying your language to setting up the search path for executables.

Here’s the key point:

• Shell variables are private to your current shell.
• Exported variables (environment variables) are inherited by any child process-like a script, program, or even another shell.

Setting Variables vs. Exporting Variables

Let’s illustrate this with a simple example:

FOO=bar

Now, in your current shell, FOO has the value bar. But if you launch a new shell or run a script, FOO isn’t visible there:

bash -c 'echo $FOO'  # Output: (nothing)

Now, let’s export it:

export FOO=bar
bash -c 'echo $FOO'  # Output: bar

By exporting, you’re telling Bash, “Hey, include this variable in the environment you give to any child process.”

Why Use export?

You might wonder why this matters. Here are a few common scenarios:

1. Passing Config to Scripts: Suppose you have a script that expects certain variables to be set, like an API key or a debug flag:

   export API_KEY="abc123" ./myscript.sh

   Inside myscript.sh, $API_KEY is available-no need to hardcode or pass it as a command-line argument.

2. Customizing Your Shell Environment: Programs and tools rely on environment variables for customization:
   • PATH: Tells Bash where to look for commands.
   • EDITOR: Sets your default text editor for programs like git.
   • LANG or LC_ALL: Tells programs what language or locale to use.

   export PATH="$PATH:$HOME/bin"
   export EDITOR=nano

3. Controlling Application Behavior: Many tools (like Python, Node.js, Java, and Docker) check the environment for settings:

   export NODE_ENV=production
   export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64

Real-World Example: Debugging with export

Imagine you’re troubleshooting a web app that isn’t picking up your configuration changes. You set a variable like so:

MY_SETTING="value" ./runserver.sh

But the app keeps complaining that MY_SETTING isn’t set. Why? Because the variable wasn’t exported-runserver.sh can’t see it.

Now, try:

export MY_SETTING="value" ./runserver.sh

Suddenly, it works. That’s the magic of export.

How to Use export in Practice

Setting and Exporting in One Step

You can set and export in a single line:

export LOG_LEVEL=debug

Exporting an Existing Variable

You can also export a variable you’ve already created:

DEBUG=true export DEBUG

Listing Exported Variables

Want to see which variables are exported? Just type:

export

or, for a more compact list:

env

Removing (Unsetting) an Exported Variable

If you want to remove a variable from the environment:

unset LOG_LEVEL

This deletes the variable from your current shell and any children.

The Lifecycle of Exported Variables

It’s important to realize that exports are only valid for the duration of your current shell session. If you open a new terminal, or restart your computer, you’ll need to set them again unless you add them to a shell startup file.

Making Exports Permanent

To make environment variables always available, add them to ~/.bashrc, ~/.bash_profile, or (on some systems) ~/.profile.

For example, add to ~/.bashrc:

export PATH="$PATH:$HOME/.local/bin"
export EDITOR=vim

Then either open a new terminal or reload the file with:

source ~/.bashrc

Now, every time you start a new shell, those variables are exported automatically.

Advanced Usage: Exporting for a Single Command

Sometimes, you only want to set a variable for one specific command. You don’t even need to use export for this-just prefix the command:

FOO=bar myscript.sh

In this case, FOO is only available to myscript.sh and doesn’t clutter your shell’s environment.

You can combine multiple variables:

FOO=bar BAZ=qux ./myscript.sh

This is a great way to run a program with temporary settings, especially when testing.

Common Pitfalls and How to Avoid Them

1. Spaces Around the Equal Sign: This is a classic mistake:

   export VAR = value   # Wrong! Will give an error.
   export VAR=value     # Correct.

2. Forgetting to Export: If you set a variable without export, it won’t be available to child processes. Always use export if you want scripts or programs to see the variable.
3. Quoting Values: If your value contains spaces or special characters, use quotes:

   export GREETING="Hello World"

4. Lifetime of Variables: Remember that exported variables exist only for the current session unless you put them in a profile file.

Environment Variables vs. Shell Variables: A Closer Look

It’s worth emphasizing the difference with an analogy:

• Shell variable: Like a note you write for yourself in your notebook.
• Environment variable: Like a sticky note you attach to a folder, so anyone who picks up the folder (i.e., any process you start) can see it.

If you only need the variable for your own use in your current terminal, don’t bother exporting. But if you want your scripts, editors, or other programs to see it, use export.

When to Use and Not Use export

Use export when:

• You want to pass configuration to child processes or scripts.
• You’re setting variables that customize the behavior of your shell or system utilities.
• You’re defining variables in your startup files for persistent use.

Don’t use export when:

• You only need the variable in your current shell (for calculations, loops, or temporary data).

Real-World Story: The Forgotten Export

Years ago, I was working on a deployment script that set the DATABASE_URL variable with a secret password before launching the app. For hours, the app kept complaining about missing credentials, even though I could echo the variable just fine in my terminal.

The culprit? I’d set DATABASE_URL without exporting it. The launch script couldn’t see the variable, because it wasn’t part of the environment. A quick export DATABASE_URL fixed the issue instantly.

Lesson learned: If your program or script can’t see your variable, check if you exported it!

Viewing and Debugging Environment Variables

See All Environment Variables:

You can dump your environment with:

env

or:

printenv

Both commands list all exported variables in your current shell.

View a Specific Variable:

echo $PATH
echo $EDITOR

Debugging Scripts:

If you’re unsure whether your script is seeing a variable, insert a debug line:

echo "DATABASE_URL is $DATABASE_URL"

Export and Subshells:

One subtlety: when you run a subshell (like with bash -c or within a script), only exported variables are visible. This is why export is so crucial for scripts and program launches.

Here’s a hands-on demo:

MYVAR=test
echo $MYVAR           # outputs: test
bash -c 'echo $MYVAR' # outputs: (nothing)
export MYVAR
bash -c 'echo $MYVAR' # outputs: test

Export in Scripting and Automation

In shell scripts, you can export variables so that any command or process called within the script has access:

#!/bin/bash
export LOG_LEVEL=debug
python3 myscript.py

Here, myscript.py can read the LOG_LEVEL variable from the environment.

If you want a variable to be available to a function but not outside the script, just set it locally (without export).

Security Note: Be Careful What You Export

Because environment variables are inherited by child processes, be cautious about exporting sensitive data, especially in multi-user environments or when launching third-party scripts. Tools like ps can sometimes reveal environment variables set for processes.

When in doubt, pass secrets via secure means or limit their scope.

Frequently Asked Questions

Can I export a variable to all open terminals at once?
No. Exported variables only apply to the current shell and its child processes. To have variables available everywhere, put them in your startup files (~/.bashrc, etc.).

Is export unique to Bash?
No, but syntax and behavior may vary slightly in other shells. The concept of exporting environment variables is standard across Unix-like systems.

How do I remove an exported variable?
Use unset VARNAME to remove it from your session.

Conclusion

The export command in Bash might seem simple, but it plays a foundational role in how your shell and programs communicate. Whenever you need to pass a setting or a piece of data to a script, a tool, or a new shell session, export is your trusty helper.

Remember: use export when you need a variable to be visible outside your own shell. Add important exports to your .bashrc or .profile to make your environment consistent and reduce surprises. And when things aren’t working, double-check sometimes the fix is just one export away.

If you’re just starting out, experiment with export in your terminal. Break things, fix them, and get comfortable. The more you practice, the more natural it will feel and the more powerful your Bash skills will become.