Shell Environment, Variables, and Startup Files

Shell Variables vs. Environment Variables

When you open a Bash terminal, the shell maintains two overlapping collections of data: shell variables and environment variables. Understanding the difference is essential for configuring a reliable development workspace.

A shell variable exists only inside the current shell process. You create one by assigning a name and value:

```bash

MY_VAR="hello"

```

No other process can see `MY_VAR`. When you launch a script or a child shell, it does not inherit this variable.

An environment variable is a shell variable that has been exported. Exporting marks the variable so that every child process the shell spawns inherits a copy of it:

```bash

export MY_VAR="hello"

```

You can combine assignment and export on one line, which is the most common style.

To inspect environment variables, use `env` or `printenv`. To see all variables — including unexported shell variables and shell functions — use `set`. The difference matters in practice: a variable you forget to export will appear in `set` output but not in `env`, and a script run as a child process will not see it.

The PATH Variable

`PATH` is one of the most important environment variables. It is a colon-separated list of directories the shell searches, in order, when you type a command name. If a directory is not in `PATH`, you must type the full path to any executable stored there.

Developers commonly create a personal `~/bin` directory to store custom scripts and small tools. To make those files available as commands, `~/bin` must be added to `PATH`:

```bash

export PATH="$HOME/bin:$PATH"

```

Placing `$HOME/bin` at the front gives your personal scripts priority over system-wide commands with the same name. Be intentional about ordering: putting an untrusted directory at the front of `PATH` is a security risk if others can write to it. Keep `~/bin` writable only by you (`chmod 700 ~/bin` or `chmod 755 ~/bin` with appropriate permissions).

Startup Files: .bashrc and .bash_profile

Bash reads different files depending on how the shell was started.

• Login shell (e.g., SSH login, switching users with `su -`): Bash reads `~/.bash_profile` (or `~/.profile` if `.bash_profile` is absent).
• Interactive non-login shell (e.g., opening a new terminal tab in a desktop environment): Bash reads `~/.bashrc`.

Because these two startup paths exist, developers use a common pattern: put all customizations in `.bashrc` and source `.bashrc` from `.bash_profile`:

```bash

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

```

This ensures your settings load regardless of how the shell starts.

Aliases defined in `.bashrc` are also limited to the current shell; they are not inherited by child processes. That is expected behavior — aliases are a convenience shortcut, not a subprocess tool.

Example alias for a common Git command:

```bash

alias gst="git status"

```

After editing `.bashrc`, apply changes to the running shell with:

```bash

source ~/.bashrc

```

or the equivalent shorthand `. ~/.bashrc`.

Setting a Project Variable

A `PROJECT_ROOT` environment variable gives scripts and tools a single, authoritative reference to your project directory. Set and export it in `.bashrc`:

```bash

export PROJECT_ROOT="$HOME/projects"

```

Scripts can then use `$PROJECT_ROOT` instead of hardcoded paths, making the workspace easier to move or reproduce.

Dotfile Portability and Setup Scripts

A dotfile is any configuration file whose name begins with a dot (`.bashrc`, `.bash_profile`, etc.). Keeping these files under version control and writing a `setup.sh` script to deploy them is a professional practice called dotfile management.

A minimal `setup.sh` might:

1. Copy your customized `.bashrc` to `~/`.

2. Copy your `.bash_profile` to `~/`.

3. Create `~/bin` if it does not exist.

4. Source `.bashrc` to apply changes immediately.

Test the script on a clean-user account to simulate a fresh environment before relying on it.

Safety and Best Practices

• Never store passwords or API keys in `.bashrc` or `.bash_profile`. These files are plain text and are readable by anyone with access to the account. Use a dedicated secrets manager or environment injection tool instead.
• Back up existing dotfiles before overwriting them. A one-line mistake can prevent login shells from starting correctly.
• Validate your `PATH` edits — a malformed `PATH` (e.g., a missing `$PATH` at the end) can make standard commands like `ls` and `cd` unavailable until you fix it. Always verify with `echo $PATH` after editing.
• Restrict permissions on `~/bin`: `chmod 755 ~/bin` prevents other users from writing executables there that could be run under your account.