\"      $NetBSD: u2,v 1.1 2007/11/29 12:35:06 mjf Exp $
\"
\" Copyright (C) Caldera International Inc.  2001-2002.
\" All rights reserved.
\"
\" Redistribution and use in source and binary forms, with or without
\" modification, are permitted provided that the following conditions
\" are met:
\" 1. Redistributions of source code and documentation must retain the above
\"    copyright notice, this list of conditions and the following disclaimer.
\" 2. Redistributions in binary form must reproduce the above copyright
\"    notice, this list of conditions and the following disclaimer in the
\"    documentation and/or other materials provided with the distribution.
\" 3. All advertising materials mentioning features or use of this software
\"    must display the following acknowledgement:
\"      This product includes software developed or owned by Caldera
\"      International, Inc.
\" 4. Neither the name of Caldera International, Inc. nor the names of other
\"    contributors may be used to endorse or promote products derived from
\"    this software without specific prior written permission.
\"
\" USE OF THE SOFTWARE PROVIDED FOR UNDER THIS LICENSE BY CALDERA
\" INTERNATIONAL, INC. AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR
\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
\" IN NO EVENT SHALL CALDERA INTERNATIONAL, INC. BE LIABLE FOR ANY DIRECT,
\" INDIRECT INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
\" (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
\" SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
\" IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
\" POSSIBILITY OF SUCH DAMAGE.
\"
\"      @(#)u2  8.1 (Berkeley) 6/8/93
\"
SH
II.  DAY-TO-DAY USE
SH
Creating Files \(em The Editor
PP
If you have to type a paper or a letter or a program,
how do you get the information stored in the machine?
Most of these tasks are done with
the
UC UNIX
``text editor''
UL ed .
Since
UL ed
is thoroughly documented in
UL ed (1)
and explained in
ul
A Tutorial Introduction to the UNIX Text Editor,
we won't spend any time here describing how to use it.
All we want it for right now is to make some
ul
files.
(A file is just a collection of information stored in the machine,
a simplistic but adequate definition.)
PP
To create a file
called
UL junk
with some text in it, do the following:
P1
ta .65i
ed junk \fR(invokes the text editor)\f3
a       \fR(command to ``ed'', to add text)\f3
ft I
now type in
whatever text you want ...
ft 3
\&.     \fR(signals the end of adding text)\f3
P2
The ``\f3.\fR'' that signals the end of adding text must be
at the beginning of a line by itself.
Don't forget it,
for until it is typed,
no other
UL ed
commands will be recognized \(em
everything you type will be treated as text to be added.
PP
At this point you can do various editing operations
on the text you typed in, such as correcting spelling mistakes,
rearranging paragraphs and the like.
Finally, you must write the information you have typed
into a file with the editor command
UL w :
P1
w
P2
UL ed
will respond with the number of characters it wrote
into the file
UL junk .
PP
Until the
UL w
command,
nothing is stored permanently,
so if you hang up and go home
the information is lost.\(dg
FS
\(dg This is not strictly true \(em
if you hang up while editing, the data you were
working on is saved in a file called
UL ed.hup ,
which you can continue with at your next session.
FE
But after
UL w
the information is there permanently;
you can re-access it any time by typing
P1
ed junk
P2
Type a
UL q
command
to quit the editor.
(If you try to quit without writing,
UL ed
will print a
UL ?
to remind you.
A second
UL q
gets you out regardless.)
PP
Now create a second file called
UL temp
in the same manner.
You should now have two files,
UL junk
and
UL temp .
SH
What files are out there?
PP
The
UL ls
(for ``list'') command lists the names
(not contents)
of any of the files that
UC UNIX
knows about.
If you type
P1
ls
P2
the response will be
P1
junk
temp
P2
which are indeed the two files just created.
The names are sorted into alphabetical order automatically,
but other variations are possible.
For example,
the command
P1
ls -t
P2
causes the files to be listed in the order in which they were last changed,
most recent first.
The
UL \-l
option gives a ``long'' listing:
P1
ls -l
P2
will produce something like
P1
-rw-rw-rw-  1 bwk  users 41 Jul 22 2:56 junk
-rw-rw-rw-  1 bwk  users 78 Jul 22 2:57 temp
P2
The date and time are of the last change to the file.
The 41 and 78 are the number of characters
(which should agree with the numbers you got from
UL ed ).
UL bwk
is the owner of the file, that is, the person
who created it.
UL users
is the name of the file's group.
The
UL \-rw\-rw\-rw\-
tells who has permission to read and write the file,
in this case everyone.
PP
Options can be combined:
UL ls\ \-lt
gives the same thing as
UL ls\ \-l ,
but sorted into time order.
You can also name the files you're interested in,
and
UL ls
will list the information about them only.
More details can be found in
UL ls (1).
PP
The use of optional arguments that begin with a minus sign,
like
UL \-t
and
UL \-lt ,
is a common convention for
UC UNIX
programs.
In general, if a program accepts such optional arguments,
they precede any filename arguments.
It is also vital that you separate the various arguments with spaces:
UL ls\-l
is not the same as
UL ls\ \ \-l .
SH
Printing Files
PP
Now that you've got a file of text,
how do you print it so people can look at it?
There are a host of programs that do that,
probably more than are needed.
PP
One simple thing is to use the editor,
since printing is often done just before making changes anyway.
You can say
P1
ed junk
1,$p
P2
UL ed
will reply with the count of the characters in
UL junk
and then print all the lines in the file.
After you learn how to use the editor,
you can be selective about the parts you print.
PP
There are times when it's not feasible to use the editor for printing.
For example, there is a limit on how big a file
UL ed
can handle
(several thousand lines).
Secondly,
it
will only print one file at a time,
and sometimes you want to print several, one after another.
So here are a couple of alternatives.
PP
First is
UL cat ,
the simplest of all the printing programs.
UL cat
simply prints on the terminal the contents of all the files
named in a list.
Thus
P1
cat junk
P2
prints one file, and
P1
cat junk temp
P2
prints two.
The files are simply concatenated (hence the name
UL cat '') ``
onto the terminal.
PP
UL pr
produces formatted printouts of files.
As with
UL cat ,
UL pr
prints all the files named in a list.
The difference is that it produces
headings with date, time, page number and file name
at the top of each page,
and
extra lines to skip over the fold in the paper.
Thus,
P1
pr junk temp
P2
will print
UL junk
neatly,
then skip to the top of a new page and print
UL temp
neatly.
PP
UL pr
can also produce multi-column output:
P1
pr -3 junk
P2
prints
UL junk
in 3-column format.
You can use any reasonable number in place of ``3''
and
UL pr
will do its best.
UL pr
has other capabilities as well;
see
UL pr (1).
PP
It should be noted that
UL pr
is
ul
not
a formatting program in the sense of shuffling lines around
and justifying margins.
The true formatters are
UL nroff
and
UL troff ,
which we will get to in the section on document preparation.
PP
There are also programs that print files
on a high-speed printer.
Look in your manual under
UL lpr .
SH
Shuffling Files About
PP
Now that you have some files in the file system
and some experience in printing them,
you can try bigger things.
For example,
you can move a file from one place to another
(which amounts to giving it a new name),
like this:
P1
mv junk precious
P2
This means that what used to be ``junk'' is now ``precious''.
If you do an
UL ls
command now,
you will get
P1
precious
temp
P2
Beware that if you move a file to another one
that already exists,
the already existing contents are lost forever.
PP
If you want
to make a
ul
copy
of a file (that is, to have two versions of something),
you can use the
UL cp
command:
P1
cp precious temp1
P2
makes a duplicate copy of
UL precious
in
UL temp1 .
PP
Finally, when you get tired of creating and moving
files,
there is a command to remove files from the file system,
called
UL rm .
P1
rm temp temp1
P2
will remove both of the files named.
PP
You will get a warning message if one of the named files wasn't there,
but otherwise
UL rm ,
like most
UC UNIX
commands,
does its work silently.
There is no prompting or chatter,
and error messages are occasionally curt.
This terseness is sometimes disconcerting
to new\%comers,
but experienced users find it desirable.
SH
What's in a Filename
PP
So far we have used filenames without ever saying what's
a legal name,
so it's time for a couple of rules.
First, filenames are limited to 14 characters,
which is enough to be descriptive.\(dg
FS
\(dg In  4.2 BSD the limit was extended to 255 characters.
FE
Second, although you can use almost any character
in a filename,
common sense says you should stick to ones that are visible,
and that you should probably avoid characters that might be used
with other meanings.
We have already seen, for example,
that in the
UL ls
command,
UL ls\ \-t
means to list in time order.
So if you had a file whose name
was
UL \-t ,
you would have a tough time listing it by name.
Besides the minus sign, there are other characters which
have special meaning.
To avoid pitfalls,
you would do well to
use only letters, numbers and the period
until you're familiar with the situation.
PP
On to some more positive suggestions.
Suppose you're typing a large document
like a book.
Logically this divides into many small pieces,
like chapters and perhaps sections.
Physically it must be divided too,
for
UL ed
will not handle really big files.
Thus you should type the document as a number of files.
You might have a separate file for each chapter,
called
P1
chap1
chap2
ft R
etc...
P2
Or, if each chapter were broken into several files, you might have
P1
chap1.1
chap1.2
chap1.3
\&...
chap2.1
chap2.2
\&...
P2
You can now tell at a glance where a particular file fits into the whole.
PP
There are advantages to a systematic naming convention which are not obvious
to the novice
UC UNIX
user.
What if you wanted to print the whole book?
You could say
P1
pr chap1.1 chap1.2 chap1.3 ......
P2
but you would get tired pretty fast, and would probably even make mistakes.
Fortunately, there is a shortcut.
You can say
P1
pr chap*
P2
The
UL *
means ``anything at all,''
so this translates into ``print all files
whose names begin with
UL chap '',
listed in alphabetical order.
PP
This shorthand notation
is not a property of the
UL pr
command, by the way.
It is system-wide, a service of the program
that interprets commands
(the ``shell,''
UL sh (1)).
Using that fact, you can see how to list the names of the files in the book:
P1
ls chap*
P2
produces
P1
chap1.1
chap1.2
chap1.3
\&...
P2
The
UL *
is not limited to the last position in a filename \(em
it can be anywhere
and can occur several times.
Thus
P1
rm *junk* *temp*
P2
removes all files that contain
UL junk
or
UL temp
as any part of their name.
As a special case,
UL *
by itself matches every filename,
so
P1
pr *
P2
prints all your files
(alphabetical order),
and
P1
rm *
P2
removes
ul
all files.
(You had better be
IT  very
sure that's what you wanted to say!)
PP
The
UL *
is not
the only pattern-matching feature available.
Suppose you want to print only chapters 1 through 4 and 9.
Then you can say
P1
pr chap[12349]*
P2
The
UL [...]
means to match any of the characters inside the brackets.
A range of consecutive letters or digits can be abbreviated,
so you can also do this
with
P1
pr chap[1-49]*
P2
Letters can also be used within brackets:
UL [a\-z]
matches any character in the range
UL a
through
UL z .
PP
The
UL ?
pattern matches any single character,
so
P1
ls ?
P2
lists all files which have single-character names,
and
P1
ls -l chap?.1
P2
lists information about the first file of each chapter
UL chap1.1 \&, (
UL chap2.1 ,
etc.).
PP
Of these niceties,
UL *
is certainly the most useful,
and you should get used to it.
The others are frills, but worth knowing.
PP
If you should ever have to turn off the special meaning
of
UL * ,
UL ? ,
etc.,
enclose the entire argument in single quotes,
as in
P1
ls \(fm?\(fm
P2
We'll see some more examples of this shortly.
SH
What's in a Filename, Continued
PP
When you first made that file called
UL junk ,
how did
the system
know that there wasn't another
UL junk
somewhere else,
especially since the person in the next office is also
reading this tutorial?
The answer is that generally each user
has a private
IT directory ,
which contains only the files that belong to him.
When you log in, you are ``in'' your directory.
Unless you take special action,
when you create a new file,
it is made in the directory that you are currently in;
this is most often your own directory,
and thus the file is unrelated to any other file of the same name
that might exist in someone else's directory.
PP
The set of all files
is organized into a (usually big) tree,
with your files located several branches into the tree.
It is possible for you to ``walk'' around this tree,
and to find any file in the system, by starting at the root
of the tree and walking along the proper set of branches.
Conversely, you can start where you are and walk toward the root.
PP
Let's try the latter first.
The basic tools is the command
UL pwd
(``print working directory''),
which prints the name of the directory you are currently in.
PP
Although the details will vary according to the system you are on,
if you give the
command
UL pwd ,
it will print something like
P1
/usr/your\(hyname
P2
This says that you are currently in the directory
UL your-name ,
which is in turn in the directory
UL /usr ,
which is in turn in the root directory
called by convention just
UL / .
(Even if it's not called
UL /usr
on your system,
you will get something analogous.
Make the corresponding mental adjustment and read on.)
PP
If you now type
P1
ls /usr/your\(hyname
P2
you should get exactly the same list of file names
as you get from a plain
UL ls  :
with no arguments,
UL ls
lists the contents of the current directory;
given the name of a directory,
it lists the contents of that directory.
PP
Next, try
P1
ls /usr
P2
This should print a long series of names,
among which is your own login name
UL your-name .
On many systems,
UL usr
is a directory that contains the directories
of all the normal users of the system,
like you.
PP
The next step is to try
P1
ls /
P2
You should get a response something like this
(although again the details may be different):
P1
bin
dev
etc
lib
tmp
usr
P2
This is a collection of the basic directories of files
that
the system
knows about;
we are at the root of the tree.
PP
Now try
P1
cat /usr/your\(hyname/junk
P2
(if
UL junk
is still around in your directory).
The name
P1
/usr/your\(hyname/junk
P2
is called the
UL pathname
of the file that
you normally think of as ``junk''.
``Pathname'' has an obvious meaning:
it represents the full name of the path you have to follow from the root
through the tree of directories to get to a particular file.
It is a universal rule in
the
UC UNIX
system
that anywhere you can use an ordinary filename,
you can use a pathname.
PP
Here is a picture which may make this clearer:
P1 1
ft R
if t .vs 9p
if t .tr /\(sl
if t .tr ||
ce 100
(root)
/ | \e
/  |  \e
/   |   \e
 bin    etc    usr    dev   tmp
/ | \e   / | \e   / | \e   / | \e   / | \e
/  |  \e
/   |   \e
adam  eve   mary
/        /   \e        \e
            /     \e       junk
junk temp
ce 0
br
tr //
P2
LP
Notice that Mary's
UL junk
is unrelated to Eve's.
PP
This isn't too exciting if all the files of interest are in your own
directory, but if you work with someone else
or on several projects concurrently,
it becomes handy indeed.
For example, your friends can print your book by saying
P1
pr /usr/your\(hyname/chap*
P2
Similarly, you can find out what files your neighbor has
by saying
P1
ls /usr/neighbor\(hyname
P2
or make your own copy of one of his files by
P1
cp /usr/your\(hyneighbor/his\(hyfile yourfile
P2
PP
If your neighbor doesn't want you poking around in his files,
or vice versa,
privacy can be arranged.
Each file and directory has read-write-execute permissions for the owner,
a group, and everyone else,
which can be set
to control access.
See
UL ls (1)
and
UL chmod (1)
for details.
As a matter of observed fact,
most users most of the time find openness of more
benefit than privacy.
PP
As a final experiment with pathnames, try
P1
ls /bin /usr/bin
P2
Do some of the names look familiar?
When you run a program, by typing its name after the prompt character,
the system simply looks for a file of that name.
It normally looks first in your directory
(where it typically doesn't find it),
then in
UL /bin
and finally in
UL /usr/bin .
There is nothing magic about commands like
UL cat
or
UL ls ,
except that they have been collected into a couple of places to be easy to find and administer.
PP
What if you work regularly with someone else on common information
in his directory?
You could just log in as your friend each time you want to,
but you can also say
``I want to work on his files instead of my own''.
This is done by changing the directory that you are
currently in:
P1
cd /usr/your\(hyfriend
P2
(On some systems,
UL cd
is spelled
UL chdir .)
Now when you use a filename in something like
UL cat
or
UL pr ,
it refers to the file in your friend's directory.
Changing directories doesn't affect any permissions associated
with a file \(em
if you couldn't access a file from your own directory,
changing to another directory won't alter that fact.
Of course,
if you forget what directory you're in, type
P1
pwd
P2
to find out.
PP
It is usually convenient to arrange your own files
so that all the files related to one thing are in a directory separate
from other projects.
For example, when you write your book, you might want to keep all the text
in a directory called
UL book .
So make one with
P1
mkdir book
P2
then go to it with
P1
cd book
P2
then start typing chapters.
The book is now found in (presumably)
P1
/usr/your\(hyname/book
P2
To remove the directory
UL book ,
type
P1
rm book/*
rmdir book
P2
The first command removes all files from the directory;
the second
removes the empty directory.
PP
You can go up one level in the tree of files
by saying
P1
cd ..
P2
UL .. '' ``
is the name of the parent of whatever directory you are currently in.
For completeness,
UL . '' ``
is an alternate name
for the directory you are in.
SH
Using Files instead of the Terminal
PP
Most of the commands we have seen so far produce output
on the terminal;
some, like the editor, also take their input from the terminal.
It is universal in
UC UNIX
systems
that the terminal can be replaced by a file
for either or both of input and output.
As one example,
P1
ls
P2
makes a list of files on your terminal.
But if you say
P1
ls >filelist
P2
a list of your files will be placed in the file
UL filelist
(which
will be created if it doesn't already exist,
or overwritten if it does).
The symbol
UL >
means ``put the output on the following file,
rather than on the terminal.''
Nothing is produced on the terminal.
As another example, you could combine
several files into one by capturing the output of
UL cat
in a file:
P1
cat f1 f2 f3 >temp
P2
PP
The symbol
UL >>
operates very much like
UL >
does,
except that it means
``add to the end of.''
That is,
P1
cat f1 f2 f3 >>temp
P2
means to concatenate
UL f1 ,
UL f2
and
UL f3
to the end of whatever is already in
UL temp ,
instead of overwriting the existing contents.
As with
UL > ,
if
UL temp
doesn't exist, it will be created for you.
PP
In a similar way, the symbol
UL <
means to take the input
for a program from the following file,
instead of from the terminal.
Thus, you could make up a script of commonly used editing commands
and put them into a file called
UL script .
Then you can run the script on a file by saying
P1
ed file <script
P2
As another example, you can use
UL ed
to prepare a letter in file
UL let ,
then send it to several people with
P1
mail adam eve mary joe <let
P2
SH
Pipes
PP
One of the novel contributions of
the
UC UNIX
system
is the idea of a
ul
pipe.
A pipe is simply a way to connect the output of one program
to the input of another program,
so the two run as a sequence of processes \(em
a pipeline.
PP
For example,
P1
pr f g h
P2
will print the files
UL f ,
UL g ,
and
UL h ,
beginning each on a new page.
Suppose you want
them run together instead.
You could say
P1
cat f g h >temp
pr <temp
rm temp
P2
but this is more work than necessary.
Clearly what we want is to take the output of
UL cat
and
connect it to the input of
UL pr .
So let us use a pipe:
P1
cat f g h | pr
P2
The vertical bar
UL |
means to
take the output from
UL cat ,
which would normally have gone to the terminal,
and put it into
UL pr
to be neatly formatted.
PP
There are many other examples of pipes.
For example,
P1
ls | pr -3
P2
prints a list of your files in three columns.
The program
UL wc
counts the number of lines, words and characters in
its input, and as we saw earlier,
UL who
prints a list of currently-logged on people,
one per line.
Thus
P1
who | wc
P2
tells how many people are logged on.
And of course
P1
ls | wc
P2
counts your files.
PP
Any program
that reads from the terminal
can read from a pipe instead;
any program that writes on the terminal can drive
a pipe.
You can have as many elements in a pipeline as you wish.
PP
Many
UC UNIX
programs are written so that they will take their input from one or more files
if file arguments are given;
if no arguments are given they will read from the terminal,
and thus can be used in pipelines.
UL pr
is one example:
P1
pr -3 a b c
P2
prints files
UL a ,
UL b
and
UL c
in order in three columns.
But in
P1
cat a b c | pr -3
P2
UL pr
prints the information coming down the pipeline,
still in
three columns.
SH
The Shell
PP
We have already mentioned once or twice the mysterious
``shell,''
which is in fact
UL sh (1).
The shell is the program that interprets what you type as
commands and arguments.
It also looks after translating
UL * ,
etc.,
into lists of filenames,
and
UL < ,
UL > ,
and
UL |
into changes of input and output streams.
PP
The shell has other capabilities too.
For example, you can run two programs with one command line
by separating the commands with a semicolon;
the shell recognizes the semicolon and
breaks the line into two commands.
Thus
P1
date; who
P2
does both commands before returning with a prompt character.
PP
You can also have more than one program running
ul
simultaneously
if you wish.
For example, if you are doing something time-consuming,
like the editor script
of an earlier section,
and you don't want to wait around for the results before starting something else,
you can say
P1
ed file <script &
P2
The ampersand at the end of a command line
says ``start this command running,
then take further commands from the terminal immediately,''
that is,
don't wait for it to complete.
Thus the script will begin,
but you can do something else at the same time.
Of course, to keep the output from interfering
with what you're doing on the terminal,
it would be better to say
P1
ed file <script >script.out &
P2
which saves the output lines in a file
called
UL script.out .
PP
When you initiate a command with
UL & ,
the system
replies with a number
called the process number,
which identifies the command in case you later want
to stop it.
If you do, you can say
P1
kill process\(hynumber
P2
If you forget the process number,
the command
UL ps
will tell you about everything you have running.
(If you are desperate,
UL kill\ 0
will kill all your processes.)
And if you're curious about other people,
UL ps\ a
will tell you about
ul
all
programs that are currently running.
PP
You can say
P1 1
(command\(hy1; command\(hy2; command\(hy3) &
P2
to start three commands in the background,
or you can start a background pipeline with
P1
command\(hy1 | command\(hy2 &
P2
PP
Just as you can tell the editor
or some similar program to take its input
from a file instead of from the terminal,
you can tell the shell to read a file
to get commands.
(Why not? The shell, after all, is just a program,
albeit a clever one.)
For instance, suppose you want to set tabs on
your terminal, and find out the date
and who's on the system every time you log in.
Then you can put the three necessary commands
UL tabs , (
UL date ,
UL who )
into a file, let's call it
UL startup ,
and then run it with
P1
sh startup
P2
This says to run the shell with the file
UL startup
as input.
The effect is as if you had typed
the contents of
UL startup
on the terminal.
PP
If this is to be a regular thing,
you can eliminate the
need to type
UL sh :
simply type, once only, the command
P1
chmod +x startup
P2
and thereafter you need only say
P1
startup
P2
to run the sequence of commands.
The
UL chmod (1)
command marks the file executable;
the shell recognizes this and runs it as a sequence of commands.
PP
If you want
UL startup
to run automatically every time you log in,
create a file in your login directory called
UL .profile ,
and place in it the line
UL startup .
When the shell first gains control when you log in,
it looks for the
UL .profile
file and does whatever commands it finds in it.\(dg
FS
\(dg The c shell instead reads a file called
UL .login

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.