|
|
UNIX/Linux Tutorial
1.10.3 Permissions Dependencies | 1.10.4 Changing Permissions
1.11 Managing File Links | 1.11.1 Hard Links | 1.11.2 Symbolic Links
1.12 Job Control | 1.12.1 Jobs And Processes |
1.12.2 Foreground And Background | 1.12.3 Backgrounding And Killing Jobs
1.10.3 Permissions Dependencies
The permissions granted to a file also depend on the permissions of the directory in
which the file is located. For example, even if a file is set to -rwxrwxrwx, other users
cannot access the file unless they have read and execute access to the directory in which the
file is located. For example, if Larry wanted to restrict access to all of his files, he could
set the permissions to his home directory /home/patrick to -rwx------. In this way, no
other user has access to his directory, and all files and directories within it. Patrick
doesn't need to worry about the individual permissions on each of his files.
In other words, to access a file at all, you must have execute access to all directories
along the file's pathname, and read (or execute) access to the file itself.
Typically, users on a Linux system are very open with their files. The usual set of
permissions given to files is -rw-r--r--, which lets other users read the file but not
change it in any way. The usual set of permissions given to directories is -rwxr-xr-x,
which lets other users look through your directories, but not create or delete files within
them.
However, many users wish to keep other users out of their files. Setting the permissions
of a file to -rw------- will prevent any other user from accessing the file. Likewise, setting
the permissions of a directory to -rwx------ keeps other users out of the directory
in question.
1.10.4 Changing Permissions
The command chmod is used to set the permissions on a file. Only the owner of a file
may change the permissions on that file. The syntax of chmod is:
chmod {a,u,g,ogo} {+,-} {r, w, x } xg filenames
Briefly, you supply one or more of all, user, group, or other. Then you specify whether
you are adding rights (+) or taking them away (-). Finally, you specify one or more of
read, write, and execute. Some examples of legal commands are:
chmod a+r stuff
Gives all users read access to the file.
chmod +r stuff
Same as above—if none of a, u, g,or o is specified, a is assumed.
chmod og-x stuff
Remove execute permission from users other than the owner.
chmod u+rwx stuff
Let the owner of the file read, write, and execute the file.
chmod o-rwx stuff
Remove read, write, and execute permission from users other than the
owner and users in the file's group.
1.11 Managing File Links
Links let you give a single file more than one name. Files are actually identified by the
system by their inode number, which is just the unique file system identifier for the file.
A directory is actually a listing of inode numbers with their corresponding filenames. Each
filename in a directory is a link to a particular inode.
1.11.1 Hard Links
The ln command is used to create multiple links for one file. For example, let's say
that you have a file called foo in a directory. Using ls -i, you can look at the inode
number for this file:
/home/patrick # ls -i foo
22192 foo
/home/patrick #
Here, foo has an inode number of 22192 in the file system. You can create another link to
foo, named bar, as follows:
/home/patrick # ln foo bar
With ls -i, you see that the two files have the same inode:
/home/patrick # ls - i foo bar
22192 bar 22192 foo
/ home / patrick #
Now, specifying either foo or bar will access the same file. If you make changes to foo,
those changes appear in bar as well. For all purposes, foo and bar are the same file.
These links are known as hard links because they create a direct link to an inode. Note
that you can hard-link files only when they're on the same file system; symbolic links (see
below) don't have this restriction.
When you delete a file with rm, you are actually only deleting one link to a file. If you
use the command:
/ home / patrick # rm foo
then only the link named foo is deleted, bar will still exist. A file is only truly deleted
on the system when it has no links to it. Usually, files have only one link, so using the rm
command deletes the file. However, if a file has multiple links to it, using rm will delete
only a single link; in order to delete the file, you must delete all links to the file.
The command ls -l displays the number of links to a file (among other information).
/ home / patrick # ls - l foo bar
-rw-r--r-- 2 root root 12 Aug 5 16 : 51 bar
-rw-r--r-- 2 root root 12 Aug 5 16 : 50 foo
/ home / patrick #
The second column in the listing, "2", specifies the number of links to the file.
As it turns out, a directory is actually just a file containing information about link-to-inode
associations. Also, every directory contains at least two hard links: "." (a link
pointing to itself), and ".." (a link pointing to the parent directory). The root
directory (/)".." link just points back to /. (In other words, the parent of the root
directory is the root directory itself.).
1.11.2 Symbolic Links
Symbolic links, or symlinks, are another type of link, which are different from hard
links. A symbolic link lets you give a file another name, but doesn't link the file by inode.
The command ln -s creates a symbolic link to a file. For example, if you use the
command:
/ home / patrick # ln - s foo bar
you will create a symbolic link named bar that points to the file foo. If you use ls -i,
you'll see that the two files have different inodes, indeed.
/home/patrick# ls - i foo bar
22195 bar 22192 foo
/home/patrick#
However, using ls -l, we see that the file bar is a symlink pointing to foo:
/home/patrick # ls -l foo bar
lrwxrwxrwx 1 root root 3 Aug 5 16:51 bar -> foo
-rw-r--r-- 1 root root 12 Aug 5 16:50 foo
/ home / patrick #
The file permissions on a symbolic link are not used (they always appear as
rwxrwxrwx). Instead, the permissions on the symbolic link are determined by the
permissions on the target of the symbolic link (in our example, the file foo).
Functionally, hard links and symbolic links are similar, but there are differences. For
one thing, you can create a symbolic link to a file that doesn't exist; the same is not true
for hard links. Symbolic links are processed by the kernel differently than are hard links,
which is just a technical difference but sometimes an important one. Symbolic links are
helpful because they identify the file they point to; with hard links, there is no easy way to
determine which files are linked to the same inode.
Links are used in many places on the Linux system. Symbolic links are especially
important to the shared library images in /lib.
1.12 Job Control
1.12.1 Jobs And Processes
Job control is a feature provided by many shells (including bash and tcsh) that
let you control multiple running commands, or jobs, at once. Before we can delve much
further, we need to talk about processes.
Every time you run a program, you start what is called a process. The command ps
displays a list of currently running processes, as shown here:
/ home / patrick # ps
PID TT STAT TIME COMMAND
24 3 S 0:03 (bash)
161 3 R 0:00 ps
/ home / patrick #
The PID listed in the first column is the process ID, a unique number given to every
running process. The last column, COMMAND, is the name of the running command. Here,
we're looking only at the processes which Patrick is currently running. (There are
many other processes running on the system as well—"ps -aux" lists them all.) These
are bash (Patrick's shell), and the ps command itself. As you can see, bash is running
concurrently with the ps command. bash executed ps when Patrick typed the command.
After ps has finished running (after the table of processes is displayed), control is returned
to the bash process, which displays the prompt, ready for another command.
A running process is also called a job. The terms process and job are interchangeable.
However, a process is usually referred to as a "job" when used in conjunction with job
control—a feature of the shell that lets you switch between several independent jobs.
In most cases users run only a single job at a time—whatever command they last typed
to the shell. However, using job control, you can run several jobs at once, and switch
between them as needed.
How might this be useful? Let's say you are editing a text file and want to interrupt
your editing and do something else. With job control, you can temporarily suspend the
editor, go back to the shell prompt and start to work on something else. When you're done,
you can switch back to the editor and be back where you started, as if you didn't leave the
editor. There are many other practical uses of job control.
1.12.2 Foreground And Background
Jobs can either be in the foreground or in the background. There can only be one
job in the foreground at a time. The foreground job is the job with which you interact.It
receives input from the keyboard and sends output to your screen, unless, of course, you
have redirected input or output. On the other hand, jobs in the background do not receive
input from the terminal—in general, they run along quietly without the need for
interaction.
Some jobs take a long time to finish and don't do anything interesting while they are
running. Compiling programs is one such job, as is compressing a large file. There's no
reason why you should sit around being bored while these jobs complete their tasks; just
run them in the background. While jobs run in the background, you are free to run other
programs.
Jobs may also be suspended. A suspended job is a job that is temporarily stopped. After
you suspend a job, you can tell the job to continue in the foreground or the background
as needed. Resuming a suspended job does not change the state of the job in any way. The
job continues to run where it left off.
Suspending a job is not equal to interrupting a job. When you interrupt a running process
(by pressing the interrupt key, which is usually Ctrl-C ), the process is killed, for good.
Once the job is killed, there's no hope of resuming it. You'll must run the command
again. Also, some programs trap the interrupt, so that pressing Ctrl-C won't immediately
kill the job. This is to let the program perform any necessary cleanup operations
before exiting. In fact, some programs don't let you kill them with an interrupt at all.
1.12.3 Backgrounding And Killing Jobs
Let's begin with a simple example. The command yes is a seemingly useless command
that sends an endless stream of y's to standard output. (This is actually useful. If you piped
the output of yes to another command which asked a series of yes and no questions, the
stream of y's would confirm all of the questions.)
Try it out:
/home/patrick# yes
y
y
y
y
y
The y's will continue ad infinitum. You can kill the process by pressing the interrupt key,
which is usually Ctrl-C . So that we don't have to put up with the annoying stream of (3)
y's, let's redirect the standard output of yes to /dev/null. As you may remember,
/dev/null acts as a "black hole" for data. Any data sent to it disappears. This is
a very effective method of quieting an otherwise verbose program.
/home/patrick# yes > > /dev/null
Ah, much better. Nothing is printed, but the shell prompt doesn't come back. This is
because yes is still running, and is sending those inane y's to /dev/null. Again, to kill
the job, press the interrupt key.
(3)You can set the interrupt key with the stty command.
Let's suppose that you want the yes command to continue to run but wanted to get
the shell prompt back so that you can work on other things. You can put yes into the
background, allowing it to run, without need for interaction.
One way to put a process in the background is to append an "&" character to the
end of the command:
/home/patrick# yes > > /dev/null &
[1] 164
/home/patrick #
As you can see, the shell prompt has returned. But what is this "[1] 164"? And is the
yes command really running?
The "[1]" represents the job number for the yes process. The shell assigns a job
number to every running job. Because yes is the one and only job we're running, it is
assigned job number 1.The"164" is the process ID, or PID, number given by the system
to the job. You can use either number to refer to the job, as you'll see later.
You now have the yes process running in the background, continuously sending a
stream of y's to /dev/null. To check on the status of this process, use the internal shell
command jobs:
/home/patrick# jobs
[1]+ Running yes > / dev / null &
/home/patrick #
Sure enough, there it is. You could also use the ps command as demonstrated above to
check on the status of the job.
To terminate the job, use the kill command. This command takes either a job number
or a process ID number as an argument. This was job number 1, so using the command:
/home/patrick # kill %1
kills the job. When identifying the job with the job number, you must prefix the number
with a percent ("%") character.
Now that you've killed the job, use jobs again to check on it:
/home/patrick# jobs
[1]+ Terminated yes > / dev / null
/home/patrick#
The job is in fact dead, and if you use the jobs command again nothing should be printed.
You can also kill the job using the process ID (PID) number, displayed along with the
job ID when you start the job. In our example, the process ID is 164, so the command:
/home/patrick# kill 164
is equivalent to:
/home/patrick# kill %1
You don't need to use the "%" when referring to a job by its process ID.
1.1 Introduction 1.2.10 Referring To Home Directories 1.3.4 Copying Files
1.6 Exploring The File System 1.8 Wildcards 1.9.3 Pipes 1.10.3 Permissions Dependencies
1.12.4 Stopping And Restarting Jobs 1.13.3 Inserting Text 1.13.9 Including Other Files
1.14.3 Shell Initialization Scripts System Administration 2.3.1 The /etc/imitate file
2.4 Managing File Systems 2.6 Managing Users 2.6.5 Groups 2.7.2 gzip and compress
2.8.3 Making Backups To Tape Devices 2.9.1 Upgrading The Kernel
2.9.3 Installing A Device Driver Module
BOOK: LINUX QUICK COMMAND REFERENCE
http://personal.atl.bellsouth.net/~psadler
© copyright KnowledgeWorks, Inc. (2001)