exportPass variables to the programs you start
export marks a shell variable so it's copied into the environment of every command the shell starts from then on. It's how you hand a database URL, AWS profile or extended PATH to your app, kubectl or terraform.
export [-n] [-f] NAME[=VALUE]... | export -pYour app can't see DB_HOST even though echo shows it. Find out why.
exportA shell builtin: it changes the shell's own variables, so it can't be a separate program.
bash keeps every variable in its own memory with attributes such as readonly, integer and exported. export sets the exported attribute (it's the same as declare -x). Nothing is sent anywhere at that moment. When bash later runs a program, it forks, and in the child calls execve with an envp array built from all variables marked exported. The new program gets a copy of those strings. Because it's a copy, a child can never change its parent's variables: a script that exports something affects only itself and its own children, and the change is gone when it exits. That's why settings meant for your current shell go through source, and settings meant to survive logins go in ~/.profile or ~/.bashrc (or /etc/environment, which pam_env reads at login). sudo resets the environment by default (env_reset in sudoers), so exported variables usually don't reach commands run with sudo.
export only sets a flag; at execve the shell copies flagged variables to the child, and nothing ever flows back.
DB_HOST=db.internal stores the value in bash's own memory. It's a shell variable: echo sees it, nothing else does.
export NAME=VALUESet and export in one stepexport NAMEExport an existing shell variableexport -pList exported variables (as declare -x lines)export -n NAMERemove the export flag; the shell variable staysexport -f FUNCExport a bash function to child bash processesNAME=VALUE cmdNot export: set it for one command onlydeclare -x / declare -p NAMESame as export / show a variable and its attributesexport PATH=/opt/app/binIt replaces the whole PATH, so ls, grep and everything else become 'command not found' in this shell.
export PATH="$PATH:/opt/app/bin"export DB_HOST = db.internalSpaces turn it into three words; bash complains `=': not a valid identifier.
export DB_HOST=db.internalRunning ./set-env.sh to set variables for your sessionThe script runs in a child process; its exports vanish when it exits.
source ./set-env.shexport AWS_SECRET_ACCESS_KEY=... typed at the promptIt's saved in ~/.bash_history and passed to every program you start.
Use aws configure / an SSO profile, or prefix with a space when HISTCONTROL=ignorespaceTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a variable APP_ENV=staging without exporting it, and prove a child shell can't see it. Then export it and prove it can.
Add ~/app/scripts to the end of your PATH for this session, then run deploy.sh by name.
List all exported variables and count them.
Show that sudo drops an exported variable, then pass it through.
exportPass variables to the programs you start
export marks a shell variable so it's copied into the environment of every command the shell starts from then on. It's how you hand a database URL, AWS profile or extended PATH to your app, kubectl or terraform.
export [-n] [-f] NAME[=VALUE]... | export -pYour app can't see DB_HOST even though echo shows it. Find out why.
exportA shell builtin: it changes the shell's own variables, so it can't be a separate program.
bash keeps every variable in its own memory with attributes such as readonly, integer and exported. export sets the exported attribute (it's the same as declare -x). Nothing is sent anywhere at that moment. When bash later runs a program, it forks, and in the child calls execve with an envp array built from all variables marked exported. The new program gets a copy of those strings. Because it's a copy, a child can never change its parent's variables: a script that exports something affects only itself and its own children, and the change is gone when it exits. That's why settings meant for your current shell go through source, and settings meant to survive logins go in ~/.profile or ~/.bashrc (or /etc/environment, which pam_env reads at login). sudo resets the environment by default (env_reset in sudoers), so exported variables usually don't reach commands run with sudo.
export only sets a flag; at execve the shell copies flagged variables to the child, and nothing ever flows back.
DB_HOST=db.internal stores the value in bash's own memory. It's a shell variable: echo sees it, nothing else does.
export NAME=VALUESet and export in one stepexport NAMEExport an existing shell variableexport -pList exported variables (as declare -x lines)export -n NAMERemove the export flag; the shell variable staysexport -f FUNCExport a bash function to child bash processesNAME=VALUE cmdNot export: set it for one command onlydeclare -x / declare -p NAMESame as export / show a variable and its attributesexport PATH=/opt/app/binIt replaces the whole PATH, so ls, grep and everything else become 'command not found' in this shell.
export PATH="$PATH:/opt/app/bin"export DB_HOST = db.internalSpaces turn it into three words; bash complains `=': not a valid identifier.
export DB_HOST=db.internalRunning ./set-env.sh to set variables for your sessionThe script runs in a child process; its exports vanish when it exits.
source ./set-env.shexport AWS_SECRET_ACCESS_KEY=... typed at the promptIt's saved in ~/.bash_history and passed to every program you start.
Use aws configure / an SSO profile, or prefix with a space when HISTCONTROL=ignorespaceTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a variable APP_ENV=staging without exporting it, and prove a child shell can't see it. Then export it and prove it can.
Add ~/app/scripts to the end of your PATH for this session, then run deploy.sh by name.
List all exported variables and count them.
Show that sudo drops an exported variable, then pass it through.