terminal 105: PATH and environment variables terminal 105: PATH และตัวแปรแวดล้อม

in terminal 104 you saw the annoying version of the problem:

• the tool exists
• the install worked
• and the shell still says “command not found”

105 is where that stops feeling random.

the name for the missing mental model is PATH.

PATH is just a list of folders your shell searches when you type a command name like rg, git, or python3.

in this lesson, “environment variables” mostly means one important example: PATH. that is intentional. you do not need a full survey yet. you need one variable that explains a lot of real beginner pain immediately.

once you understand that search order, a lot of terminal confusion collapses into three simple questions:

1. does the file exist?
2. is its folder in PATH?
3. if more than one copy exists, which one wins?

what you’ll know by the end

• what PATH is in plain language
• how to inspect it with echo $PATH
• how to ask which file wins with which
• how to make a temporary PATH change with export
• why PATH counts as an environment variable in the first place
• why that temporary fix disappears in a new shell
• the footgun for this lesson: a fix you make with export only changes the current shell

what this assumes

terminal 101 through terminal 104.

if the Homebrew lesson made sense and which brew no longer feels mysterious, you’re ready for the reason underneath it.

3 commands + 1 environment variable

this lesson stays Mac-first so it connects cleanly to 104, but the mental model is broader than macOS.

the search rule is the real lesson:

the shell walks through PATH from left to right, and the first match wins

that one sentence explains both of these beginner problems:

• “why is my custom script not found even though the file exists?”
• “why is the wrong copy of python3 running?“

try it yourself

the interactive demo below is designed to make the invisible part visible.

the shipit preset is a stand-in for any small helper script you might save in ~/bin.

work through this order:

1. leave the default python3 preset selected
2. click run which
3. notice that the first python3 match wins, even though another copy exists later
4. click the shipit preset
5. click run which again
6. see the second beginner problem: the command exists, but the current PATH is not searching ~/bin
7. click echo $PATH
8. click export PATH="$HOME/bin:$PATH"
9. click run which
10. click open new shell
11. click run which one more time

the teaching moment is steps 8 through 11:

• export can fix the current shell immediately
• but it does not automatically change future shells

that’s why “it worked a second ago” and “it disappeared in the next tab” can both be true.

what PATH really is

you do not need a textbook definition here.

PATH is just a colon-separated list of directories:

echo $PATH

when you type:

rg notes

the shell does not magically know where rg lives.

it checks each PATH directory in order until it finds a matching executable. if /opt/homebrew/bin comes before /usr/bin, then commands in /opt/homebrew/bin get first chance.

that is why order matters.

why PATH is an environment variable

an environment variable is just a named piece of shell state.

PATH is one of those named values. when you run:

echo $PATH

you are asking the shell to print the current value stored under the name PATH.

that is enough environment-variable theory for now. the point is not to memorize jargon. the point is to understand that PATH is data the shell carries around, uses while resolving commands, and can change for the current session.

why which is worth learning early

which answers a very practical question:

“if i type this command name right now, what file will the shell actually run?”

examples:

which brew
which rg
which python3

if which prints a path, the shell can resolve the command.

if it cannot, you know the problem is not “typing the command wrong.” the problem is that the shell cannot find a matching file in its current search path.

that distinction saves a lot of wasted reinstalling and random copying.

what export changes, and what it does not

this line is useful:

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

it means:

• take ~/bin
• put it at the front
• keep the old PATH after it

that change affects the current shell process.

it does not rewrite history, and it does not automatically configure future shells. if you close the window or open a fresh one, the temporary change is gone unless your startup files add it again.

that is exactly why 105 comes before 106.

105 teaches the mental model. 106 teaches where to put the change so it sticks.

one real-world task

imagine you made a tiny helper script called shipit and saved it in ~/bin.

the workflow looks like this:

1. run which shipit
2. if it does not resolve, check echo $PATH
3. temporarily test with export PATH="$HOME/bin:$PATH"
4. run which shipit again
5. if which shipit now prints a path, the PATH part is fixed
6. if that fixed it, make the change persistent in your shell config instead of retyping export forever

that is a real beginner workflow because it separates three jobs cleanly:

• verify
• test the fix
• then make the fix permanent in the right place

whether the script itself runs correctly after that is a separate question. PATH only decides whether the shell can find it.

common mistakes

you treat PATH like one mysterious string instead of an ordered list. order is the whole point. leftmost directories get checked first.

you assume a file existing somewhere means the shell can run it. the shell only searches the directories currently in PATH.

you forget that export is temporary. this is the footgun for 105. if the fix vanishes in a new tab, nothing supernatural happened.

you keep guessing instead of checking with which. use the cheap evidence first.

you jump straight to editing config files without testing the idea in the current shell. a temporary export is a good experiment. if it works, then move the change into shell config.

what this unlocks

now “command not found” should feel narrower and easier to debug.

you can check PATH, see which executable wins, and prove whether a change is temporary or persistent.

next up: terminal 106 — shell config on macOS. that’s where PATH changes, aliases, and source ~/.zshrc stop being copy-paste rituals and start making sense.