متغيرات البيئة وPATH

Written Explanation

Environment variables

An environment variable is a named setting that the operating system hands to every program it starts. It has a name and a value, and the value is always text. Examples:

When one program starts another, the new program receives a copy of its parent's environment at that moment. Microsoft's PowerShell documentation describes the same idea: environment variables are inherited by child processes. The copy is taken at start time. Later changes in the parent do not appear in programs that are already running.

On Windows, variables exist at three levels, according to the same documentation: Machine (also called System), User, and Process. A new process gets a combination of the machine and user values. On macOS and Linux, names are case-sensitive, so PATH and Path would be different variables. On Windows they are not.

PATH: the list of shelves

When you type java -version, the terminal (really, the program called a shell) receives the word java. It has no idea where such a program is. So it consults PATH: a list of folders, which it searches in order, looking in each folder for a program named java. The first match is the one that runs. If no folder holds it, the shell gives up and reports an error.

Microsoft documents the format: PATH holds a list of folders, separated by a semicolon ; on Windows and a colon : on macOS and Linux.

Here is an example of a Windows PATH value (yours will be different):

C:\Windows\system32;C:\Windows;C:\Program Files\Java\jdk-<version>\bin

and a Unix-like one:

/usr/local/bin:/usr/bin:/bin:/usr/lib/jvm/java-<version>-openjdk/bin

The folder on the end contains java and javac. It is the JDK's bin folder (short for binaries, the programs). The JDK folder itself holds other directories too, and only bin contains the commands, so it is bin that must be on PATH, not the JDK folder one level up.

Because the search is in order, the order matters. If two JDKs are installed and both bin folders are on PATH, the one listed first wins. That is how the second classic mistake arises: the wrong JDK is first.

Printing PATH

The result is one long line. To make it readable, split it at the separators:

PowerShell:   $env:PATH -split ';'
Bash or Zsh:  echo "$PATH" | tr ':' '\n'

You can also ask the shell which program it would run:

where and which are standard tools on those systems, though I did not verify their exact output formats on an official page. They are the quickest way to see which of several JDKs is being picked.

A program can also read its own environment. This small Java program prints JAVA_HOME and each folder of PATH on its own line. Save it as EnvPeek.java, compile it with javac EnvPeek.java, and run it with java EnvPeek:

import java.io.File;

public class EnvPeek {
    public static void main(String[] args) {
        String javaHome = System.getenv("JAVA_HOME");
        System.out.println("JAVA_HOME = " + (javaHome == null ? "(not set)" : javaHome));

        String path = System.getenv("PATH");
        if (path == null) {
            System.out.println("PATH is not set");
            return;
        }
        String[] folders = path.split(File.pathSeparator);
        System.out.println("PATH has " + folders.length + " folders:");
        for (String folder : folders) {
            System.out.println("  " + folder);
        }
    }
}

System.getenv(name) returns the value as a String, or null if the variable does not exist, and File.pathSeparator is ; or : depending on the system. The program runs as a child of your terminal, so it prints what the terminal gave it, which proves the inheritance rule in practice.

"Command not found"

If no folder on PATH holds the command, each shell reports it in its own words. Typical messages:

'java' is not recognized as an internal or external command,
operable program or batch file.          (Command Prompt)

The term 'java' is not recognized as the name of a cmdlet, function,
script file, or operable program.        (PowerShell)

bash: java: command not found            (Bash)
zsh: command not found: java             (Zsh)

The wording may differ slightly between versions. The meaning is the same: I searched every folder on PATH and found nothing with that name. The common causes:

1. Not installed. There is no JDK on the machine.
2. Installed but not on PATH. The bin folder is not on the list.
3. Wrong folder on PATH. The entry points to the JDK folder instead of its bin folder, or contains a typo or an outdated version number.
4. Old terminal. The change was made after the terminal started, so this terminal still has the old copy.
5. Typing mistake. The command is java, not Java on a case-sensitive system, and not jave.

Work through them in that order, and answer each with a command: where or which, a printed PATH, a look at the folder on disk.

Fixing PATH for one session

The quickest repair affects only the terminal you are in. Replace the folder with your own JDK's bin folder:

PowerShell:   $env:PATH = "C:\Program Files\Java\jdk-<version>\bin;" + $env:PATH
Bash or Zsh:  export PATH="/path/to/jdk/bin:$PATH"

The PowerShell documentation confirms that a change made this way affects only the current session. The command puts the JDK folder at the front, so it wins the search. Close the window and the change is gone, which makes this an excellent way to test a fix safely.

Fixing PATH permanently

To keep a change, you edit the stored value that new terminals start from:

• Windows: The PowerShell documentation describes the route through the System Control Panel: open System, then Advanced System Settings, the Advanced tab, and Environment Variables. You can edit the User list (only you) or the System list (everyone). On newer Windows versions, searching the Start menu for "environment variables" gets you there faster. In the editor, select Path, choose Edit, and add the JDK's bin folder as a new line. Click OK on every dialog, or the change is not saved.
• macOS and Linux: Add the export PATH=... line to your shell's start-up file. The PowerShell documentation names ~/.bashrc for Bash and ~/.zshrc for Zsh as the usual files for shells started from another shell. Which file your terminal actually reads can depend on whether it is a login shell, so check your system's documentation if the change does not appear. On Linux, a package manager normally sets things up for you, as lesson 2 explained.

After a permanent change, open a new terminal and test. The terminals already open still hold the old copy.

Why a new terminal is needed

This is the rule that explains the third classic mistake. A terminal is a process. It received its environment when it started. Editing the stored PATH afterwards changes what future processes will receive, not what the existing process already has. The existing terminal cannot see the change, and nor can any program started from it. Close it and open a new one, and the new terminal starts with the fresh value. Some IDEs read the environment only when they start, too, so restart the IDE after changing PATH.

JAVA_HOME

JAVA_HOME is a variable whose value is the root folder of the JDK, for example C:\Program Files\Java\jdk-<version> or /usr/lib/jvm/java-<version>-openjdk. It is not the bin folder. Many build tools and servers read JAVA_HOME to find the JDK they should use, so it is common to set it. It is a convention: the java command does not need it to run, while other tools may.

A neat way to avoid repeating yourself is to put JAVA_HOME first and build PATH from it, as in this general pattern from Java setup guides:

JAVA_HOME = C:\Program Files\Java\jdk-<version>
PATH      = %JAVA_HOME%\bin;...other folders...

With this setup, changing to a different JDK means changing one variable. I describe this as a common practice, not a requirement, and I did not find it in Oracle's installation overview, which does not discuss the variable.