PATH : Java Glossary

An environment variable that lists the directories the command processor searches for *.exe, *.com and *.bat files, including, of course, javac.exe and java.exe. Avoid duplicate filenames, even with different extensions. You may be astonished which one executes. We need a utility to detect this problem. The path command is what you would use to set or view the PATH environment variable. You can discover what the PATH is with:

// get path via environment probe
final String pathValue = System.getPath( "path" );

// get the value of the path via the corresponding System property
final String pathValue = System.getProperty( "java.library.path" );

The path is stored in different ways on different platforms and you use different tools to set it. See environment for details on how to set it. Note the : or ; is a separator, not a terminator. You do not put one on the end of the path.

Dots in Path, Classpath and java.library.path

In Windows, a dot in the environment PATH means search the current directory. Normally you leave it out and one is presumed at the head of the PATH.

In all OSes, in the classpath, a dot means search the current directory. If you leave it out, the current directory will not be searched for class files.

Java creates the java.library.path from the environment PATH, adding to it. If it finds no dot in the PATH, it adds one at the end of the java.library.path.

In the Mac dot is automatically included in the java.library.path.

On Unix, you would leave . off the path so that a malicious user wouldn’t create an ls script in their home dir and hope that the root user executes that script. The canonical way to execute CWD (Current Working Directory) commands is ./cmdname This allows you to know exactly what you are executing.

Mac PATH

Early Macs did not have a PATH, but now that Mac OS (Operating System) is a flavour of Unix they have aquired them, yes, more than one depending on what you’ve configured where and depending on what’s doing the asking, which is routine UNIX anyway.

How does the OS know where to look for executables? Well, when you are in the GUI (Graphic User Interface) environment you are telling it, by selecting the executable yourself. Applications can configure their own dependencies (plists). There is also an Apple replacement for service control called launchd, that has a conf file and also understands plists (launchd replaces, or is meant to replace, things like init and rc and inetd and crond etc.).

In a console environment you are now more directly in a UNIX environment. With a recent Mac OS X (Tiger, Leopard, Snow Leopard, Lion) you have intermingling combinations of shell configuration file (e.g. .bashrc) PATH exports, entries in /etc/paths (file) and entries in /etc/paths.d (directory). I believe the path_helper tool looks at .profile config files in addition.

Paths for libraries (shared) is done on Mac OS X in a fashion similar to other UNIXes. That is, there are similar but not identical ways to specify runtime library paths both through flags and environment variables, for all UNIXes.

Gotchas

You would think java.library.path would just be a straight forward copy of your path. However, the process of creating it is strange. It duplicates entries and scrambles the order. Further it adds the non-existent directory C:\WINDOWS\Sun\java\bin\. What may be happening is Java wants to be sure sure certain directories are present, so it adds them, without checking if they are already there.

I need to do some experiments to see if you can dynamically modify the PATH and java.library.path and whether that has any effect on Runtime.exec().