The shell environment

Before you read. A backup script works perfectly when you run it. The same script, on the same machine, from cron at 2am, fails with command not found, for a command that is definitely installed and that you have just run successfully.

Nothing about the machine changed between the two runs. The file is the same file.

What is different about the second run?

Something invisible came with the first one and not the second. Every process carries a set of variables it inherited from whatever started it, and one of those variables decides where the shell looks for commands.

Your interactive session builds that set from several files over several steps. A cron job gets almost none of it, which is deliberate and is the correct behaviour, and is the source of an entire genre of 2am failures.

Some words you will need

environment variable

A named value a process carries and passes on to anything it starts.

shell variable

The same thing without the passing on. It exists only in the shell that set it.

PATH

A list of directories the shell searches, in order, to find a command you typed.

login shell

The shell you get when you log in. Reads a different startup file from the others.

interactive shell

One with a prompt, waiting for you to type. A script is neither interactive nor login.

What breaks without this

Scripts fail on a schedule and nowhere else. The single most common “it worked yesterday” in this exam’s territory.

A service cannot find what you can. Services run with their own environment, which is neither yours nor cron’s, and adding something to your shell profile does not reach them.

You cannot explain a wrong answer. Locale settings change how sort orders things and how dates are formatted, silently, and a script producing different output on two machines is very often this.

What is in there

env prints the whole environment. The ones worth recognising:

SHELL is a trap worth knowing about. It reports the shell listed for your account, not the one you are in. Start zsh from bash and SHELL still says bash. ps -p $$ answers the real question.

Setting, and passing on

# Debian 13 (trixie), x86_64
$ GREETING=hello; echo "set: $GREETING"; sh -c 'echo "child sees: [$GREETING]"'; export GREETING; sh -c 'echo "after export, child sees: [$GREETING]"'
set: hello
child sees: []
after export, child sees: [hello]

That is the whole of export in three lines. A plain assignment makes a shell variable, which the shell can see and nothing it starts can. export promotes it to an environment variable, which every child process inherits.

Note the direction: inheritance flows downward only. A child cannot change its parent’s environment, which is why cd has to be a shell builtin, a program changing its own directory would achieve nothing, and why a script that sets a variable cannot affect the shell that ran it. source script.sh (or . script.sh) runs it in the current shell instead, which is how a script changes your environment and the only way it can.

unset NAME removes it. VAR=value command sets it for that one command only, which is the cleanest way to test a theory:

LC_ALL=C sort file.txt
DEBUG=1 ./thescript.sh

How a command is found

# Debian 13 (trixie), x86_64
$ bash -c 'echo "$PATH"; echo "--- what kind of thing is each of these ---"; type ls; type cd; type -a echo'
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
--- what kind of thing is each of these ---
ls is /usr/bin/ls
cd is a shell builtin
echo is a shell builtin
echo is /usr/bin/echo
echo is /bin/echo

PATH is a colon-separated list, searched left to right, first match wins. Type ls and the shell tries /usr/local/sbin/ls, then /usr/local/bin/ls, then /usr/sbin/ls, then finds /usr/bin/ls and stops.

cd is a shell builtin, so it is never searched for at all, which is why which cd finds nothing and people conclude it does not exist.

echo is both, and the builtin wins because builtins are checked before PATH. That is why echo’s behaviour differs slightly between shells while /bin/echo stays constant.

Prefer type interactively and command -v in scripts. which is a separate binary that only searches PATH, so it misses builtins, functions, and aliases, and it is not installed everywhere.

When type says a name is an alias and you want the real thing, there are three answers and they are not equivalent. unalias name removes it for the rest of the session, and unalias -a removes every alias you have. A backslash in front of the name, \ls, bypasses the alias for that one command and leaves it in place, which is usually what you want. And command ls does the same job in a script, where a backslash is easy to lose in quoting.

First match wins, and why that matters

# Debian 13 (trixie), x86_64
$ mkdir -p /usr/local/bin; printf '#!/bin/sh\necho "the one in /usr/local/bin"\n' > /usr/local/bin/hostname; chmod +x /usr/local/bin/hostname; echo '--- which one wins? ---'; command -v hostname; hostname; echo '--- and every match, in order ---'; bash -c 'type -a hostname'
--- which one wins? ---
/usr/local/bin/hostname
the one in /usr/local/bin
--- and every match, in order ---
hostname is /usr/local/bin/hostname
hostname is /usr/bin/hostname
hostname is /bin/hostname

Which file runs when

This is the part that catches everyone, and it is testable:

# Debian 13 (trixie), x86_64
$ printf 'echo "bashrc ran"\n' > /root/.bashrc; printf 'echo "profile ran"\n' > /root/.bash_profile; echo '--- a login shell ---'; bash -lc 'echo done'; echo '--- an interactive non-login shell ---'; bash -ic 'echo done' 2>/dev/null; echo '--- a plain script, neither ---'; bash -c 'echo done'
--- a login shell ---
profile ran
done
--- an interactive non-login shell ---
bashrc ran
done
--- a plain script, neither ---
done

Three kinds of shell, three different answers. Read that output carefully, because it explains most of this lesson’s failures.

The third row is the important one. A script reads no startup file at all. Not .bashrc, not .bash_profile, not /etc/profile. Anything you put in those files is invisible to it.

Why most people’s .bash_profile sources .bashrc: because otherwise an SSH session would get the profile and miss everything in .bashrc. The conventional line is:

[ -f ~/.bashrc ] && . ~/.bashrc

which is why editing .bashrc usually appears to work for both cases. The profile is quietly forwarding to it. On a machine where that line is missing, the same edit works in a desktop terminal and not over SSH, which is a genuinely confusing few minutes.

/etc/profile.d/*.sh is where system-wide settings belong, not in /etc/profile itself, a drop-in file survives a package upgrade and an edit to the main file may not.

The 2am failure

# Debian 13 (trixie), x86_64
$ echo '--- your interactive PATH finds it ---'; command -v useradd; echo '--- with the PATH cron gives you, it does not ---'; env -i PATH=/usr/bin:/bin /bin/sh -c 'command -v useradd || echo "useradd: not found"'; echo '--- the full path always works ---'; env -i PATH=/usr/bin:/bin /bin/sh -c '/usr/sbin/useradd --help 2>&1 | head -1'
--- your interactive PATH finds it ---
/usr/sbin/useradd
--- with the PATH cron gives you, it does not ---
useradd: not found
--- the full path always works ---
Usage: useradd [options] LOGIN

Locale, and why two machines disagree

LANG and the LC_* variables decide language, and also sorting, number formatting, and date formatting. That second group causes real problems:

• sort orders differently under different collations. In many locales it ignores case and punctuation; under LC_ALL=C it is plain byte order. Two machines with different locales produce different sorted output from the same input.
• Decimal separators change. Some locales use a comma, which breaks anything parsing numbers.
• date formats change, so a log parser written against one machine’s output fails on another.

LC_ALL=C in scripts whose output is compared or parsed. It is not a workaround; it is the correct setting for machine-readable output, and the reason build systems set it.

locale prints the current settings and locale -a lists what is available. A machine reporting LC_ALL= empty and LANG=C.UTF-8 is the common server default, and it is a sensible one.

Across distributions

Two of those cause real trouble. The system-wide bashrc filename differs by one character and a script that appends to the wrong one silently does nothing. And the /etc/sysconfig versus /etc/default split means a unit file’s EnvironmentFile= path is not portable between the families.

Prove it

When something works for you and not for something else:

# What do I have
echo "$PATH"
env | sort | head -20

# What is this command, really
type -a thecommand

# What would it look like with almost nothing
env -i PATH=/usr/bin:/bin /bin/sh -c 'command -v thecommand'

# What does the service actually have
sudo cat /proc/$(pgrep -f theservice | head -1)/environ | tr '\0' '\n'
systemctl show -p Environment theservice

The env -i line is the one to reach for first. It reproduces the minimal-environment case in a second, rather than scheduling a cron job and waiting.

What trips people up

1. Works when typed, fails from cron

PATH. Cron gives a minimal one and reads no startup files.

Full paths in scheduled jobs, or a PATH= line at the top of the crontab. And test with env -i PATH=/usr/bin:/bin ./script.sh rather than waiting for 2am.

2. The wrong startup file

.bashrc for interactive shells, .bash_profile for login shells, neither for scripts and services.

If an SSH session does not pick up your aliases, check that .bash_profile sources .bashrc. If a service does not see a variable, neither file will ever help. It needs Environment= or EnvironmentFile=.

3. Setting a variable without exporting it

A plain assignment is a shell variable. Child processes see nothing.

export VAR=value, or VAR=value command for a single command. env | grep VAR confirms it is exported; echo $VAR does not, because that works for both kinds.

4. A script that cannot change your shell

Running ./setenv.sh starts a child, which sets its own variables and exits, taking them with it.

source setenv.sh or . setenv.sh runs it in the current shell. This is why tools that modify your environment tell you to source their script rather than run it, and why cd inside a script does not move you.

5. Assuming ~ and $HOME are set

Cron and some services run with a minimal environment where HOME may be missing or different, so ~/.config/thing resolves somewhere unexpected or fails outright.

Use absolute paths in anything unattended.

Work it through

A nightly report script runs from cron. It produces a file, but the rows are in a different order from when you run it by hand, and a downstream tool that expects sorted input rejects it intermittently.

#!/bin/bash
psql -At -c "select name from customers" | sort > /reports/names.txt

Reason it out before reading on.

It is not PATH this time. The script runs, psql is found, and a file is produced. command not found is the obvious environment failure and this is a different one.

sort is the suspect, and locale is why. Sorting is locale-dependent: under most en_US.UTF-8 collations, case and punctuation are largely ignored, so apple, Banana, cherry sorts in that order. Under LC_ALL=C it is byte order, so all the capitals come before all the lowercase and it is Banana, apple, cherry.

Your interactive session has a locale; cron’s environment may not. You get LANG=en_US.UTF-8 from /etc/profile and your own files. The cron job reads neither, so it falls back to the C locale, and produces a different, equally correct, ordering.

Confirm it in one command, without waiting for the next scheduled run:

env -i /bin/bash -c 'printf "apple\nBanana\ncherry\n" | sort'
LANG=en_US.UTF-8 /bin/bash -c 'printf "apple\nBanana\ncherry\n" | sort'

Two different orderings from the same input proves the mechanism.

The fix is to stop depending on the ambient locale, in the script itself:

#!/bin/bash
set -euo pipefail
export LC_ALL=C
psql -At -c "select name from customers" | sort > /reports/names.txt

Not “set the locale to match my session”, pin it, so the output is the same regardless of who runs it, on which machine, with which login files.

Now the point worth extracting, because it generalises past locale: the environment is an input to your program, and an input nobody wrote down. The script has no bug in it. It behaves differently because it was handed different inputs by two different launchers, and neither launcher is wrong.

The habit: anything that runs unattended should declare what it needs rather than inherit it. Set PATH, set LC_ALL, use absolute paths, and pass configuration explicitly. Then the 2am run and the run you just did are actually the same run, which is the only way “it works on my machine” stops being a sentence anyone has to say.

Try it

Optional, on any machine.

1. env | sort | less. Find PATH, HOME, and LANG.
2. MYVAR=test, then bash -c 'echo "[$MYVAR]"'. Then export MYVAR and repeat.
3. type -a ls, type -a cd, type -a echo. Explain each answer.
4. echo $PATH | tr ':' '\n' to see the search order one directory per line.
5. env -i PATH=/usr/bin:/bin /bin/sh -c 'command -v useradd' and see it fail.
6. printf "apple\nBanana\ncherry\n" | sort, then the same with LC_ALL=C in front. Two orderings.
7. bash -lc 'echo login' versus bash -c 'echo script' with an echo in your .bashrc, and see which one runs it.

Verification step. You have it when you can take a script that fails from cron and reproduce the failure interactively in one command, without editing the script or waiting for a schedule.

Check yourself

References

• bash(1) - Linux man-pages project. Accessed 2026-08-07.
• environ(7) - Linux man-pages project. Accessed 2026-08-07.
• env(1) - Linux man-pages project. Accessed 2026-08-07.
• execve(2) - Linux man-pages project. Accessed 2026-08-07.
• locale(7) - Linux man-pages project. Accessed 2026-08-07.

Every block above with a distribution and architecture header was captured by running the command on a Debian 13 (trixie) container. Blocks without one are illustrative.