After logging in, type pwd at your Linux prompt, and you will see something like this:
This is a path; in this case, the path for my home directory. A directory is where files are kept. They can also contain other directories. The path /home/williams is shorthand for “The directory williams which is in the directory home, local, which is in the root directory of the file system.” Each word between / characters is a name; what it names is a directory. The pwd command reported /home/williams to me, because it was my “Present Working Directory,” more commonly known as the current or default directory.
The current directory is a simple idea with many faces. Immediately after logging in, it is your home directory. Later, it could be any directory on your file system. Your current directory is really that of your shell. Other processes have their own, which change independently. A single process with multiple sub-windows may even maintain a current directory for each.
It is useful to be aware that a command-line user will say “I am in /etc/skel”, while a graphical interface user of the same system would report that /etc/skel is “open”. Both mean the same thing. The current directory is the assumed target of your commands and any files requested. Paths let you refer to other directories. Unfortunately, learning to use them can be needlessly painful due to the historical choice of nomenclature.
Nomenclature describes how things are named. The / symbol, in path names, suffers from a nomenclature quirk known as overloading, which means it can be correctly interpreted in more than one way.
If a path begins with /, the meaning is “the root”. The root is itself a directory. [Note that /, meaning the root directory of the file system, should not be confused with /root, a directory in the / directory—Ed] Think of it as the boss directory which isn't contained by any other. Beginners often fail to “see” root at all, because the visual impact of a leading / is small. This is a serious error. A / between two directory names, after root, merely separates them. The / is not a directory—it is just a delimiter. Try this simple test to see if you've got it. How many directories are there in /home/williams?
The answer is three, not two. The two most first-year students in my course get are /home and /home/williams. About a quarter every term fail to count the root itself. If we step beyond paths to files, the nomenclature becomes ambiguous. No matter how closely we inspect /home/williams/foo, we cannot deduce whether foo is a file or a directory. If the name were /home/williams/foo.txt, we might believe foo.txt is a file, but it is possible for directories to have extensions, and common for files to omit them.
What do the following two examples tell you about the names lists and weba? (The cd [Change Directory] command resets your current directory.)
Example 1 $ cd /home/lynda/lists $ pwd /home/lynda/lists
Example 2 $ cd /home/lynda/weba bash: /home/lynda/weba: Not a directory $ pwd /home/ftp/pub/weba
You should be able to deduce that lists is a directory, but weba isn't. Of course, there are plenty of ways, starting with past experience, to resolve ambiguity. The file command is another, as are the -F and -l options for the ls command.
So far, all my paths have begun with the root. Path names which begin this way have the same meaning no matter what the current directory is. They are called absolute paths. For example, the command:
$ cd /home/ftp/pub/weba
will make /home/ftp/pub/weba my new current directory regardless of the existing one. What would the command below achieve?
$ cd webaAny reference to a file or directory which does not begin with a slash (/) is relative. This begs the question “relative to what?” Relative to the current directory. The command above, therefore, will work as desired only if my current directory is already /home/ftp/pub. Consider the following attempts to use relative paths to change directories. The prompt has changed to show the current directory before the $ symbol, and I have taken liberties with spacing to enhance readability.
Example 1 (success) /home $ cd ftp/pub /home/ftp/pub $ Example 2 (failure) /home $ cd pub bash: pub: No such file or directory /home $ example 3 (failure) /home $ cd /ftp/pub bash: /ftp/pub: No such file or directory /home $ example 4 (success) /home $ cd .. / $Relative paths are just absolute paths with the current directory assumed as a prefix. They are more common than absolute ones, as we tend to work out of the directory of greatest interest to us at the moment. Note, however, that it is wrong to start one with a /, as in example 3, because doing so makes the path absolute. Sticklers for syntax will note we lose a delimiter / in the bargain.
Two special components in building relative paths, are . and .. which stand for “this directory” and “the directory containing this directory ”, respectively. You can use them alone, as in example 4, or with other components as in this fairly typical example of backing up and going forward to a different directory:
/home/ftp $ cd ../williams /home/williams $
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide