There are several tools and techniques that go along with the editor, all of which are relatively easy once you know how ed works, because they are all based on the editor. In this section we will give some fairly cursory examples of these tools, more to indicate their existence than to provide a complete tutorial. More information on each can be found in [3].
Sometimes you want to find all occurrences of some word or pattern in a set of files, to edit them or perhaps just to verify their presence or absence. It may be possible to edit each file separately and look for the pattern of interest, but if there are many files this can get very tedious, and if the files are really big, it may be impossible because of limits in ed.
The program
grep
was invented to get around these limitations.
The search patterns that we have described in the paper are often
called `regular expressions', and
`grep' stands for
g/re/p
That describes exactly what
grep
does _
it prints every line in a set of files that contains a
particular pattern.
Thus
grep 'thing' file1 file2 file3 ...
finds `thing' wherever it occurs in any of the files
`file1',
`file2',
etc.
grep
also indicates the file in which the line was found,
so you can later edit it if you like.
The pattern represented by `thing' can be any pattern you can use in the editor, since grep and ed use exactly the same mechanism for pattern searching. It is wisest always to enclose the pattern in the single quotes '...' if it contains any non-alphabetic characters, since many such characters also mean something special to the UNIXcommand interpreter (the `shell'). If you don't quote them, the command interpreter will try to interpret them before grep gets a chance.
There is also a way to find lines that
don't
contain a pattern:
grep -v 'thing' file1 file2 ...
finds all lines that
don't contains `thing'.
The
-v
must occur in the position shown.
Given
grep
and
grep -v,
it is possible to do things like selecting all lines that
contain some combination of patterns.
For example, to get all lines that contain `x' but not `y':
grep x file... | grep -v y
(The notation | is a `pipe',
which causes the output of the first command to be used as
input to the second command; see [2].)
If a fairly complicated set of editing operations is to be done on a whole set of files, the easiest thing to do is to make up a `script', i.e., a file that contains the operations you want to perform, then apply this script to each file in turn.
For example, suppose you want to change every
`Unix' to `UNIX' and every `Gcos' to `GCOS' in a large number of files.
Then put into the file `script' the lines
g/Unix/s//UNIX/g
g/Gcos/s//GCOS/g
w
q
Now you can say
ed file1 <script
ed file2 <script
...
This causes
ed
to take its commands from the prepared script.
Notice that the whole job has to be planned in advance.
And of course by using the UNIXcommand interpreter, you can cycle through a set of files automatically, with varying degrees of ease.
sed (`stream editor') is a version of the editor with restricted capabilities but which is capable of processing unlimited amounts of input. Basically sed copies its input to its output, applying one or more editing commands to each line of input.
As an example, suppose that we want to do the `Unix' to `UNIX'
part of the
example given above,
but without rewriting the files.
Then the command
sed 's/Unix/UNIX/g' file1 file2 ...
applies the command
`s/Unix/UNIX/g'
to all lines from `file1', `file2', etc.,
and copies all lines to the output.
The advantage of using
sed
in such a case is that it can be used
with input too large for
ed
to handle.
All the output can be collected in one place,
either in a file or perhaps piped into another program.
If the editing transformation is so complicated
that
more than one editing command is needed,
commands can be supplied from a file,
or on the command line,
with a slightly more complex syntax.
To take commands from a file, for example,
sed -f cmdfile input-files...
sed has further capabilities, including conditional testing and branching, which we cannot go into here.
I am grateful to Ted Dolotta for his careful reading and valuable suggestions.