Linux export Command: Environment Variables Without the Mystery

The Linux export command looks simple, but it is behind a lot of hosting problems: missing application secrets, cron jobs that behave differently from SSH sessions, service units that cannot find a binary, and scripts that work in one terminal but fail in another.

Target system and scope

This guide is for Bash-compatible shells on typical Linux hosting systems, including Ubuntu/Debian servers, RHEL/Alma/Rocky Linux servers, and CloudLinux/cPanel environments. The examples are shell-level examples, not WordPress, PHP, or systemd unit syntax.

What export actually does

export marks a shell variable so it is placed in the environment inherited by child processes. DigitalOcean’s updated tutorial describes it as the Bash built-in that passes variables and functions down to child processes. DigitalOcean export command guide

POSIX defines export as the shell utility that gives variables the export attribute so they appear in the environment of subsequently executed commands. POSIX export(1p) manual

Shell variable vs environment variable

A shell variable exists in the current shell:

# Target: Bash on Ubuntu/Debian, RHEL-family, or CloudLinux
APP_ENV=production
echo "$APP_ENV"

A child process does not automatically receive that variable:

# Target: Bash on Linux
APP_ENV=production
bash -c 'echo "$APP_ENV"'

After export, the child process inherits it:

# Target: Bash on Linux
export APP_ENV=production
bash -c 'echo "$APP_ENV"'

Correct syntax: no spaces around equals

Shell assignments do not use spaces around =. Use NAME=value, not NAME = value. DigitalOcean calls out the standard assignment form in its practical examples. DigitalOcean syntax examples

# Correct: Bash on Linux
export PROJECT_ROOT="/var/www/example"

# Incorrect: the shell reads this as a command named PROJECT_ROOT
PROJECT_ROOT = "/var/www/example"

Common hosting patterns

Temporarily set a variable for one command

For one command, prefer an inline environment assignment. It avoids polluting the rest of your shell session:

# Target: Bash on Linux, one-off command environment
APP_ENV=staging php artisan config:show

Export a variable for child scripts

Use export when a script or subprocess needs to read the value:

# Target: Bash on Linux
export BACKUP_DIR="/home/example/backups"
./run-backup.sh

Append to PATH safely

When modifying PATH, append or prepend to the existing value instead of replacing it. DigitalOcean’s tutorial uses the safe pattern export PATH="$PATH:/new/directory". DigitalOcean PATH example

# Target: Bash on Linux
export PATH="$HOME/bin:$PATH"

Persistence: where should it go?

Use shell startup files only when the variable belongs to interactive shell sessions. DigitalOcean recommends ~/.bashrc for interactive shells, ~/.bash_profile or ~/.profile for login shells, and /etc/environment for system-wide variables. DigitalOcean persistence guidance

Interactive user shell

# Target: Bash interactive shell on Ubuntu/Debian or RHEL-family
printf '%s\n' 'export EDITOR=nano' >> ~/.bashrc
. ~/.bashrc

System services

For systemd-managed services, do not rely on your SSH shell’s exported variables. Put service-specific environment in the unit file or an EnvironmentFile, then reload systemd and restart the service. systemd.exec documents Environment=, EnvironmentFile=, and related execution-environment settings for services. systemd.exec environment settings This avoids the common mistake of expecting export in a terminal to affect already-running daemons.

cron jobs

Cron starts commands with a minimal environment. Put required variables directly in the crontab or source a dedicated, readable environment file from the script. The crontab(5) manual specifies environment-setting lines in crontabs and the default SHELL, LOGNAME, and HOME values. crontab(5) environment rules DigitalOcean notes that sudo and cron generally do not inherit your shell environment automatically. DigitalOcean cron and sudo note

Useful troubleshooting commands

# Target: Bash on Linux - list exported variables
export -p

# Target: POSIX-style environment print
printenv APP_ENV

# Target: Bash on Linux - remove variable from export list without deleting it
export -n APP_ENV

GNU Bash documents export as a shell built-in, which matters because it changes the current shell’s environment state; an external program could not modify the parent shell after it exits. GNU Bash built-ins reference

Verification checklist

1. Run printenv NAME to confirm the variable is exported.
2. Run bash -c 'echo "$NAME"' to confirm a child shell can see it.
3. Test the real execution context: SSH shell, cron, systemd service, PHP-FPM pool, or deployment runner.
4. Do not put secrets in world-readable files or command histories.

Bottom line

export is not a permanent configuration system. It is a shell mechanism for passing variables from a parent shell to child processes. Once that rule is clear, most environment-variable bugs become easier to diagnose: check which process starts which child, where the variable is defined, and whether that exact execution path receives it.