Environment Variables and Shell Startup

What you will be able to do

• Distinguish a shell variable from a value exported to child processes.
• Inspect PATH and command resolution without changing the environment first.
• Identify which Bash startup file applies to an interactive, login, or non-interactive shell.
• Troubleshoot a command that works in a terminal but fails under a service, scheduled job, or elevated context.

01

Inspect the process environment before editing startup files

An environment belongs to a process. A terminal, an SSH session, a scheduled job, and a system service can run as the same account yet receive different variables, working directories, and command-search paths. Start by identifying the process context instead of assuming every launch reads your personal Bash files.

Use `id` for the effective account, `pwd` for the working directory, `printf '%s\n' "$PATH"` for the exact search path, and `command -v name` or `type -a name` to see what Bash will execute. Use `env` or `printenv` when you need the exported environment; use `declare -p NAME` when you need Bash's current definition of one variable.

Capture only the variables relevant to the failure. Environment output can contain tokens, proxy credentials, or session identifiers, so do not paste a complete dump into a ticket or public log.

$ printf 'user=%s\ncwd=%s\n' "$(id -un)" "$PWD"
user=ana
cwd=/srv/reporting
$ command -v report-sync
/home/ana/.local/bin/report-sync

The terminal runs as `ana` from `/srv/reporting` and resolves `report-sync` from a per-user directory. A service or scheduled job can have different values even under the same account.

Capture identity, working directory, and resolved executable before changing startup files; those observations define the environment that actually works.

02

Know what export changes

`PROJECT=skillcoded` creates a shell variable in the current Bash process. A child process will not receive it until `export PROJECT` is used, or until assignment and export are combined as `export PROJECT=skillcoded`. Export affects commands started afterward; it does not rewrite the environment of a process that is already running.

For a value needed by one command only, use an assignment prefix such as `LC_ALL=C sort input.txt`. That limits the override to the launched command instead of permanently changing the current shell. Use `unset PROJECT` when the current shell should no longer retain the value.

Do not use environment variables as a general secret store. They can be inherited, logged, included in diagnostics, or exposed by process-management tools depending on the system. Use the application's approved credential mechanism and reveal only whether a required variable exists, not its value.

$ PROJECT=skillcoded
$ sh -c 'printf "<%s>\n" "${PROJECT-unset}"'
<unset>
$ export PROJECT
$ sh -c 'printf "<%s>\n" "$PROJECT"'
<skillcoded>

The first child shell did not inherit the unexported variable. After `export`, a newly started child received the value.

Export changes inheritance for future child processes; it does not update an already running process or guarantee that a service receives the same environment.

03

Treat PATH as an ordered command-resolution policy

When a command name contains no slash, Bash searches directories from left to right in `PATH`. That means a correct executable can still lose to an alias, function, hashed location, or earlier directory. `type -a python` shows every interpretation Bash knows about, while `command -v python` shows the command selected for normal execution.

$ command -v python
/home/ana/.local/bin/python
$ sudo sh -c 'command -v python || echo not-found'
/usr/bin/python

The two shells resolve `python` differently because the elevated shell has a different environment and search path.

Configure the job with the intended absolute executable or a minimal trusted path instead of copying the user's entire `PATH` into a privileged context.

If a trusted per-user tool belongs in the search path, a deliberate form is `export PATH="$HOME/.local/bin:$PATH"`. First confirm that the directory exists, is owned appropriately, and is not writable by untrusted users. Avoid an empty entry or `.` in privileged search paths because it allows the working directory to influence which program runs.

After changing `PATH`, repeat `command -v` and run the tool's version check. If Bash retained an older executable location, `hash -r` clears its command-location cache. The verification is the resolved absolute executable plus expected behavior, not merely the presence of text in `.bashrc`.

04

Use HOME, PWD, and OLDPWD for their actual shell roles

`HOME` identifies the current account's home directory for Bash features such as `cd` without an argument and tilde expansion. Do not build a path by guessing `/home/$USER`; service accounts and centrally managed users can have different home locations. Quote expansions such as `"$HOME/.config/app"` when the result is used as one pathname.

Bash maintains `PWD` as the current working directory and `OLDPWD` as the previous one set by `cd`. `cd -` uses the previous directory. These variables are useful context, but an operational script should still set or verify its working directory when relative paths matter.

`PS1` controls the primary interactive prompt. It can improve orientation, but it is not evidence that a service, script, or another shell received the same environment.

05

Match the startup file to the way Bash was launched

An interactive login Bash reads `/etc/profile`, then the first readable personal file among `~/.bash_profile`, `~/.bash_login`, and `~/.profile`. It does not read all three. Many configurations make the selected profile source `~/.bashrc` so interactive settings remain consistent.

An interactive non-login Bash normally reads `~/.bashrc`. This is common for a terminal opened inside an existing desktop session. A change placed only in `~/.bash_profile` can therefore appear over SSH or at a console login but not in a new terminal tab.

A non-interactive Bash does not follow the interactive startup path. If `BASH_ENV` is present, Bash expands its value and reads that file; it does not search `PATH` for it. Treat `BASH_ENV` as controlled execution input, not as a shortcut for making every script source a large interactive configuration.

06

Give services and scheduled jobs explicit configuration

A systemd service does not become reliable by depending on a developer's interactive `.bashrc`. Define required variables in the unit's approved `Environment=` or `EnvironmentFile=` configuration, use an explicit working directory when needed, and prefer an absolute executable path. Inspect the effective unit configuration and service logs after a change.

Scheduled jobs also need an explicit execution context. Set the required `PATH`, use absolute paths for important programs and files, and direct output to a controlled log or monitoring destination. Test the same command under the same account and environment used by the scheduler.

Do not assume `sudo` preserves your complete environment. Its policy can reset, keep, or reject variables, and preserving `HOME` can change which configuration a privileged program reads. Compare only approved variables and use `sudoedit` for protected text files when that is the intended workflow.

07

Test startup changes in a disposable shell

Before editing a personal startup file, record the line and behavior you intend to change. Keep aliases, prompt customization, and interactive helpers separate from variables required by automated workloads. A syntax error or unconditional output in `.bashrc` can disrupt terminals and remote commands.

Test with a new shell that matches the target mode. `bash --noprofile --norc` provides a clean Bash for comparison, `bash -l` exercises login behavior, and `bash -i` exercises interactive behavior. Remember that `source file` executes inside the current shell, so a bad assignment can alter the session you are using to recover.

After the test, verify the exact variable with `declare -p`, command resolution with `command -v`, and the expected workload. If the change affects only an interactive convenience, leave services and scheduled jobs out of that dependency.

08

Diagnose 'works in my terminal' without copying the terminal environment

Suppose `report-sync` works from an interactive terminal but systemd reports `executable file not found`. First compare the effective user, working directory, exact executable resolved by `command -v report-sync`, and the `PATH` supplied to the service. Do not copy the entire interactive environment into the unit.

Set the service to the verified absolute executable and only the variables the program requires. Reload the manager when the unit file changes, restart the service through the normal control path, and inspect both service status and logs. Then exercise the actual report transfer.

The incident is complete when the service starts under its intended identity, invokes the expected binary, produces the expected application result, and no secret or unrelated personal setting has been added to its environment.

09

Write an environment handoff that survives a new process

A shell variable stays in the current shell until it is exported. Exported values are inherited by commands started afterward; they do not update processes that already exist.

Inspect `PATH` with its order intact and verify resolution with `command -v` or `type -a`. A startup-file edit is not proof that the intended executable will run.

Interactive login, interactive non-login, and non-interactive Bash processes read different startup files. Identify the launch mode before choosing `.bash_profile`, `.bashrc`, or `BASH_ENV`.

Use `HOME`, `PWD`, `OLDPWD`, and `PS1` only for the roles Bash assigns them. Quote pathname expansions and avoid guessing a user's home directory.

Services, scheduled jobs, and elevated commands need explicit, minimal environments. Compare identity, directory, variables, and executable path, then verify the workload in the same execution context.