======Understanding and Setting the PATH======
UNIX uses the term "path" for two related concepts:
* The location of a file or directory on a hard drive. These are called File Paths, or more broadly a **URI** (yes, it is directly related to a **URL** on the Internet).
* The directories that should be scanned for executable code when you (or your desktop) enters a command.
The second definition is defined by a systemwide variable called, simply, ''PATH''. You can check your current ''PATH'' setting:
$ echo $PATH
/usr/pkg/bin:/usr/local/bin:/usr/bin:/bin:/usr/pkg/games:/home/klaatu/bin
**What This Means to You:**
When you type in a command, the computer knows it is supposed to attempt to execute the command. But how does the computer know what the command represents? Inherently, it does not. I n a much less convenient world, you "should" have to go to the directory where the command is located, and point specifically to it, and tell the computer to execute the code contained in the file:
$ cd /bin
$ ./ls
Of course that's not really possible, since in order to get to a directory containing commands, you would need to use a command. Also, it would be inconvenient, so there is the ''PATH'' variable, which your computer keeps in memory so that when you issue a command, like ''ls'' or ''aj-snapshot'' or ''synfigstudio'', it scans a defined set of directories to find out if such a command exists. If so, it executes the first such command it finds.
Create a test shell script and place it in ''~/bin''. Create a ''~/bin'' directory if you don't already have one.
$ echo '#\!/bin/bash' >> ~/bin/foo
$ echo 'echo "I told you it would work." ' >> ~/bin/foo
$ chmod +x ~/bin/foo
Now try some commands:
$ cd ~/audio/fatChanceLester
$ ls
napalmLounge.tar.gz
fantasticUniverse.tar.gz
lastChanceFester,tar.gz
$ foo
foo: Command not found.
In this example, the commands ''cd'' and ''ls'' were valid, but the nonsense command ''foo'' did not appear in any of the directories in ''PATH'', so it returned an error.
=====Setting the PATH=====
A Linux system comes with a default PATH already set. It contains important standard directories like ''/bin'' and ''/usr/bin'' and ''/usr/local/bin'' and a few others. This is enough to get you by just fine on an out-of-the-box Linux system, because those directories are where all the standard applications have been placed.
If you install major extra software, like Java, then the installer will modify your path (you give it permission to do this when you install the application as root) so that when you attempt to launch a Java application, it knows where to find Java.
$ echo $PATH
/bin:/usr/bin:/usr/local/bin:/usr/lib64/java/jre/bin
But what if you want to add things to your PATH manually? For example, there are several applications that are easiest to install either to ''/opt'' or to ''~/bin'', so you should be able to conveniently execute applications in those paths.
Setting a path is easy. There are two methods: one is temporary and one is persistent. Assuming you are intested in the persistent solution, open your ''~/.bash_profile'' in your favourite editor (if it does not exist, it's OK to create it).
Add your additional path settings to the current default systemwide PATH:
export PATH="${PATH}:/home/klaatu/bin"
This line simply takes whatever exists in the system PATH variable and appends ''/home/klaatu/bin'' to it, and then exports that value into your environment.
Save the file and log out, and then back in. If you are too busy to log out, you can load the new PATH by re-loading your profile settings:
$ source ~/.bash_profile
Now your computer scans your home directory's ''bin'' directory for any commands that it cannot first find in any of the default path locations.
$ foo
I told you it would work.
/*
======File Paths======
File system paths are foreign to most people, and yet something that people directly use every day: when you go to any website on the Internet, you are typing in part of a file system path. The path is somewhat disguised as a "URL" but it still reflects the files on someone's computer, you have only to swap out the domain name with whatever directory is holding all of the files you are looking at online. For instance, if we create a web server holding all the files in the Slackermedia website, then we might express the file path as this:
/var/www/htdocs/slackermedia/index.html
Users on the internet see a masked version of that:
http://www.slackermedia.info/index.html
But if you go deeper into the Slackermedia website, you get a sense for the actual structure of the files:
http://www.slackermedia.info/handbook/doku.php
From this, you know that within the ''slackermedia'' directory on my web server computer [redundancy intentional], there is a sub-directory called ''handbook'', and inside that directory, there is a file called ''doku.php'' (which in turn generates the pages of this book based on text files).
The point is that file paths are essential to computers and users, so that we can all identify where important files are kept, and so that we can point to them when they are needed.
=====Relative and Absolute Paths=====
Since file paths can get very long, and because sometimes we do not care about the full path, "relative" file paths were invented. Relative file paths are a way for computers and users to find files based on a commonly-agreed upon starting point. This is especially common in web development, but it is also common in good multimedia project file management.
Assume I have a project directory called ''blipmetal''. In the directory are two folders:
$ pwd
blipmetal
$ ls -1
sound
video
This is an absolute path to my JACK session file:
/home/klaatu/blipmetal/sound/jack/blipmetal.aj
This is a relative path from the ''video'' directory:
$ pwd
video
$ ../sound/jack/blipmetal.aj
The two dots are UNIXspeak for "take a step back". Starting from inside the ''video'' directory in this project, if the computer takes one step back, and then one step forward into ''sound'' directory, and another into the ''jack'' directory, then the ''blipmetal.aj'' session file can be located.
A single dot in UNIXspeak for "start here". Since the computer and a user //always// starts from where they are, it's a little extraneous, but it is specific:
$ pwd
blipmetal
$ ls -1
sound
video
$ cd ./sound/jack/
$ ls
blipmetal.aj
A project directory should relish in relativity, because if you move your project, you still want it to launch on your new computer, even if your username changes or you have it in a new subdirectory. For example, assume that you created a project on a computer that was your very first Linux install, and you didn't really know what you were doing and had not yet established any kind of organisational scheme yet. The project directory is here:
/home/janedoe/Documents/just\ messing\ around/test/blipmetal
Later, you get a new computer and do a fresh Slackware install. This time, you are more integrated with Linux culture and you have a grasp on your own artistic mission, so you organise things a little differently. Now the project directory has been moved here:
/home/jxd/video/blipmetal
Can you imagine if when you tried to open the project, it looked for all its data in ''/home/janedoe/Documents/just\ messing\ around/test/blipmetal''? It would fail to open, or if it did open, then it would have no idea where your assets were located.
Sadly, this //does// happen with some applications, because those applications have no way for you to set a relative path rule. However, even with these applications, the paths can be re-defined if something is found to be missing, and all you have to do is point it to the new root level of your project file; as long as everything is where you left it inside of your project directory, all of the paths are corrected in the application, and you're back up in running in under a minute.
*/
[[mimetypes|R]] [[start|S]] [[font|Q]]