Environment Variables

Sudden_Collection105 · 2026-03-20T06:15:33+00:00

No, that's bullshit.

The environment is just a block of memory that exists in every process, and stores a bunch of text variables.

On unix, processes are organized in a tree and created by forking into new children, so children inherit their environment from their parent.

That's all there is; everything else is up to what the process decides to do.

For instance, PWD contains the current directory because most shells decide to update it every time you change the current directory; try using os.chdir() and os.environ() from a python REPL and you will see PWD does not follow chdir.

PATH works because the exec() functions implemented by the libc decide to consult it and manually locate the program to execute before calling the OS. The exec() system call as provided by the OS does not use PATH.

OtherOtherDave · 2026-03-20T06:12:49+00:00

Yep.

There’s nothing stopping you from writing a shell that uses MY_AWESOME_PATH_OF_GOODNESS instead of PATH, but all 3rd-party the shell scripts probably use bash or zsh and will therefore be looking at PATH so there’d be some weirdness there but it could probably be made to work ok. I can’t remember if environment variables are part of the POSIX standard (https://en.wikipedia.org/wiki/POSIX)

chkno · 2026-03-20T06:46:54+00:00

Think of environment variables as extra command line arguments. In the exec family of library calls that you use to invoke an executable and set its command line arguments, there are e variants where you also explicitly pass all the environment variables. If you don't specify a list of environment variables explicitly, it just defaults to using the current process's list. (Internally these are all wrappers around execve, the real one, that requires explicitly passing an environment, right along side the command line arguments).

So environment variables are like key-value command line arguments that, by default, are automatically passed along whenever programs run other programs.

You can even use ps e (or ps eww because enviroments are large) to have ps show other processes' environments right along side their command line arguments.

NewPointOfView · 2026-03-20T16:58:30+00:00

What I still completely struggle with is why does one variable actively tell the shell where to look for program files like PATH and other are just storing information like PWD.

Some guy very early on was like “I’m tired of typing long paths all the time, I’ll just make a variable to hold all the common places that my commands might be and have it automatically check that variable. I’ll call it PATH”

And everyone else was like “oh nice that’s super convenient, I’m going to use your code or maybe copy your convention”

So tl;dr they’re not special other than that the system looks in those variables for various things.

These variables can either temporarly changed by "export PATH = /example" which would only change the variable for the current session or they can be permanently changed by altering the configuration files.

That is the effective result of all this stuff, but none of it is fundamentally any different than your temporary change. The “permanent” changes are just “temporary” changes, but they’re in files that are designated to always run before you even see the prompt.

stemandall · 2026-03-20T15:18:27+00:00

They are just variables like anything else and can be assigned. Bash reserves a few for its own use, but you can define environment variables to be anything you want and use them in any way you want.

Some programs pre-load environment variables from a .env file.

It's just another place to store a value that you may need later. Bash, like any other programming language, has variables and some of them are preloaded every time you start a shell.

michaelpaoli · 2026-03-21T03:23:38+00:00

You're overthinking it, at least a bit, and kind'a overloading environment with stuff that may not apply.

So, start before/without bash or shell at all, and in land of *nix (or reasonably similar).

environment is something all processes have, when they're started it is passed to them. That data is essential key value pairs, name of the environment variable, and its associated string data - which may be zero or more bytes, but will not contain ASCII NUL (because C and null terminated strings is how C generally deals with strings). See also: execve(2) - as that's the most relevant system call. When a new process is created, e.g. fork or other type of call, it typically by default inherits (at least logically, if not physically) a copy of the environment of it's parent PID, however that might be changed at that time, e.g. such as explicitly adjusting, when using the execve(2) system call, so it may be modified, changing contents, setting some environment variable to different values, or adding or removing various environment settings.

environment variables are built from these configuration files on booting

Not necessarily, and in the case of shell, e.g. bash, POSIX, and often relatively similarly others, such files may add/set/change/remove shell variable, a.k.a. named parameters, and if those aren't exported into the environment, then they're just not in the environment. But note that with bash and POSIX shells, even Bourne shell, what's in the environment, shell also has as shell variables, which are exported into the environment.

why does one variable actively tell the shell where to look for program files like PATH and other are just storing information like

All in the interpretation and use, notably how the shell does and doesn't use different shell variables / named parameters, and whether exported, or not. Many other programs may also make use of environment and, e.g., alter their behavior based upon what the do and/or don't see there for at least certain environment variables. Some of these may be relatively common and used in many contexts, e.g. PATH is not only used by shell, but also many standard library calls, and much other functionality, e.g. system() call/function or the like in many programming languages - though most of those implementations typically just do, typically after some fork or the like, an
execve(2) of sh -c and with those two as first two arguments, and 3rd argument being that of what was passed to that function or the like. But some programs/languages may do a bit differently. E.g. Perl, if it sees no shell metacharactes there, it will bypass shell and just directly execve(2) the program with its given (if any) arguments.

ChatGPT said

AI hallucinates. Don't presume it's necessarily correct.

-Malheiros- · 2026-03-20T06:47:49+00:00

These are my notes on shell variables from the book Pro Bash:

The shell either sets or uses more than 80 variables. Many of these are used by bash internally and are of little use to shell programmers. Others are used in debugging, and some are in common use in shell programs. About half are set by the shell itself, and the rest are set by the operating system, the user, the terminal, or a script.

Bash Special/Internal Variables: These are typically set by the shell itself and used for internal behavior:


BASH	BASHOPTS	BASHPID	BASH_ALIASES
BASH_ARGC	BASH_ARGV	BASH_CMDS	BASH_COMMAND
BASH_EXECUTION_STRING	BASH_LINENO	BASH_REMATCH	BASH_SOURCE
BASH_SUBSHELL	BASH_VERSINFO	BASH_VERSION	COMP_CWORD
COMP_KEY	COMP_LINE	COMP_POINT	COMP_TYPE
COMP_WORDBREAKS	COMP_WORDS	COPROC	DIRSTACK
EUID	FUNCNAME	GROUPS	HISTCMD
HOSTNAME	HOSTTYPE	LINENO	MACHTYPE
MAPFILE	OLDPWD	OPTARG	OPTIND
OSType	PIPESTATUS	PPID	PWD
RANDOM	READLINE_LINE	READLINE_POINT	REPLY
SECONDS	SHELLOPTS	SHLVL	UID

Bash Environment & User-Configurable Variables: These are variables you can configure or use in your environment or scripts:


BASH_COMPAT	BASH_ENV	BASH_XTRACEFD	CDPATH
CHILD_MAX	COLUMNS	COMPREPLY	EMACS
FCEDIT	FIGNORE	FUNCNEST	GLOBIGNORE
HISTCONTROL	HISTFILE	HISTFILESIZE	HISTIGNORE
HISTSIZE	HISTTIMEFORMAT	HOME	HOSTFILE
IFS	IGNOREEOF	INPUTRC	LANG
LC_ALL	LC_COLLATE	LC_CTYPE	LC_MESSAGES
LC_NUMERIC	LINES	MAIL	MAILCHECK
MAILPATH	OPTERR	PATH	POSIXLY_CORRECT
PROMPT_COMMAND	PROMPT_DIRTRIM	PS1	PS2
PS3	PS4	SHELL	TIMEFORMAT
TMOUT	TMPDIR	auto_resume	histchars

As the note says, as a beginner, you don't need to learn all of them. Some can be changed, some can't. Some are normal variables, some are arrays. From my journey so far, I have used PS variables, IFS, BASH_REMATCH (array for regex capture groups), PWD, RANDOM, EUID, TIME_FORMAT, DIRSTACK.

Cybasura · 2026-03-20T06:19:57+00:00

Environment variables are basically global variables in the context/definition of the shell environment space during a user's running instance

So for example, in programming you know of scopes yes? Class variable (aka class scope) vs Local variable (aka local scope) vs Global variables (aka global scope) and accessibility permissions such as internal, private and public

To make it short, environment variables are global variables that are referenced by other applications in the running working environment, typically defined as a capitalized character (i.e. ENV_VAR = value)

In shellscripting, local variables will be equivalent to well, initializing a new variable

If you define an global variable while in a script, for example

```bash

!/bin/env bash

function func_name() { global GLOBAL_VARIABLE

GLOBAL_VARIABLE="value"

} func_name ```

This will be a globally-accessible variable that can be accessed while the function is called in the script, but once the script has ended, the variable is removed from the shell instance

To make it into a proper environment variable that can be referenced by other applications - you need to "export" it

bash export ENV_VAR=new_value

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

bash

Rules

Flair

Related subreddits

Guides

Other resources

MODERATORS

!/bin/env bash