Category : Word Processors
Archive   : USEDI.ZIP
Filename : SFILES-A.1

File: SFILES-A.1
a part of U-SEDIT1.ZIP
Version 1 - January 19, 1990

Written by Mike Arst, Box 5, 1407 E. Madison St., Seattle, WA 98122.
FidoNet address: send netmail in care of 1:343/8.0.

All text is Copyright 1990 Mike Arst.

You may copy these files and transmit them in *unaltered* form to
computer bulletin boards. You may print out the text of the files
and/or photocopy the printouts for personal use. This text may
not be reproduced or published for any other purpose, by any
means now known or to be later developed, without the express
written permission of its author.

No one may charge a fee specifically for the distribution of this
file nor for the distribution of the others in the U-SEDIT1.ZIP
archive file (with "?" representing a version number), which
files include U-SED-IT.1, REGEXP.1, REFORMAT.INF, SFILES-A.1,
SFILES-B.1, and SED.EXE.

Copyright notices, and all language related to usage of this
text, must be retained in the files.

All proprietary names herein, such as Microsoft, DOS, MS-DOS,
UNIX, and so on, are the property of their various owners, blah
blah blah.

If you upload the U-SEDIT archive to a bulletin board, please
upload it with all files that were in it when you got it.


If you have not already read the text file U-SED-IT.1 and if you
have not used SED before, I would suggest you take a spin through
U-SED-IT.1 and through REGEXP.1 before proceeding.


SED SCRIPT FILES

You can do a tremendous amount with SED script files - much more
than can be done on the DOS command line - but who the devil
knows HOW to do this "tremendous amount"? What follows is the sum
total of what I know right now about script files. Verbose as it
might seem, it's only a drop in the bucket.


APOLOGIES ...

I would like to have been able to write about the commands used
to manipulate SED's memory buffers called work space and the hold





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 1




space, but to be honest: the SED docs I had before I began
writing these files are so hard to follow, it's virtually
impossible to understand what the devil they're talking about
with regard to manipulating the hold space. In this version of
the documentation concerning script files I'm going to have to
leave most of that stuff out. Sorry about that. There'll be more
on manipulating the hold space, I hope, in a future version of
this file.


AND OTHER PRELIMINARIES

A SED script file is a plain ASCII text file. Do not save it in,
say, WordStar "document mode" format, nor in the proprietary
format of a word processor like Microsoft Word or Word Perfect.

If there is an end-of-file (CTRL Z) character in a script file,
SED will not read past that character. If you have put the CTRL Z
character on a non-blank line in the script file, SED might not
read the line properly. In other words, this (with "EOF"
representing the end-of-file mark) probably won't work:

s/hello/goodbye/g
s/garbage/what a mess/gEOF

If you feel you gotta put a CTRL Z into the file, better do it
as follows:

s/hello/goodbye/g
s/garbage/what a mess/g
EOF

Why bother with a CTRL Z at all? It might come in handy if you
want to include comments about the editing instructions in a
script file. Some versions of SED allow you to include comments
as follows:

s/yes/no/g # change "yes" to "no"

Nothing on the line is read to the right of the # character.
The version of SED included with this documentation doesn't
support such a use of #. UNIX SED does - but do you have a UNIX
terminal right in front of you? Oh. Well, lucky you ...

You can't simply place the comments on the lines with the
instructions, then; but you can put them below an end-of-file
marker. Then you can use a program like LIST.COM to view the
comments.

Ah - you're going to be clever about it, eh? You're going to type
the instruction, then a NULL character, and then the comment.





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 2





That won't work either. SED will stop reading at the NULL, all
right - and then it won't read *anything* else in the script file.
Nice try, though.

A SED instruction which would have to be delimited (surrounded)
by " marks on the command line does NOT have to be quoted
within a script file. If you type at the DOS prompt:

sed "s/hello, there/goodbye/g" inputfile

in a script file the substitution would look like this:

s/hello/goodbye/g

In other words, it contains the editing or other instruction(s)
and none of the switches or quote marks you'd have to use on the
command line (nor the input file name).

Many kinds of commands that would be entered at the DOS prompt
can indeed be placed into a script file. Examples:

1,3p

or:

/hello/,$ s/goodbye/go away/g

If you have a "p" operator in a script file instruction, remember
that to avoid double printing of some, perhaps all, lines SED
prints, you'll need to include an "-n" switch in the DOS command
line. Thus:

sed -n -f scriptfile inputfile


LIMITATIONS ON NUMBER OF INSTRUCTIONS

I once tried to use a SED script that contained 130 or so
instructions - very simple ones, like: s/x/y/g - but SED bombed
out, saying that it had reached its limit at about the 100th
instruction. I then removed all instructions from number 101
through the last one - and SED bombed again. I removed one more
instruction, leaving 99, and it worked. The "overflow" was placed
into a second script file, and the entire command was executed as
follows:

sed -f script1 inputfile | sed -f script2 > outputfile

where "script1" was the file containing 99 instructions and
"script2" contained the rest.





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 3





Whether SED will terminate due to the number of instructions, or
rather due to memory limitations (which would vary with the
complexity of the instructions, not just the number of 'em), I
don't know.


NESTING COMMANDS

SED uses the { and } characters to mark the beginning and
end of grouped (nested) commands. For example, if you would like
to perform a series of commands on a given line or group of lines
before moving on to the next instructions:

1,20{
s/hello/goodbye
/junk/d
/^$/d
}

The above grouped editing commands would be restricted to lines 1
through and including 20 *before* any other instruction was
processed which might affect lines 1 through 20. As with other
SED commands which can include ranges of lines, you can refer to
text on specific lines, rather than line numbers:

/^Hello/,/goodbye.$/{
s/hello/goodbye/g
/junk/d
/^$/d
}

Here the editing commands would be performed on all lines falling
within this range: a line beginning with "Hello," down to and
including (and no farther than) a line that ends with "goodbye."

Notice how the brackets are placed. As far as I can tell, the
"open" bracket must be the last character on the line that
specifies the range of input-file lines to process. The "close"
bracket must be *on its own line*. You can indent text in a script
file to make it a little easier to read, thus:

5,10 {
s/hello/goodbye/g
/^$/d
}

Most of the time, the indentation of editing instructions from
the left margin won't have any effect; SED ignores any leading
spaces or TABs. There are exceptions, however. See the section,
below, on the "a" (insert text) command.





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 4





QUOTE MARKS IN SCRIPT FILES

If you have given a SED editing instruction on the command line
and if it must be surrounded by double quote marks, *and* if it
contains a double quote mark as part of the searched-for text
(Whew. Lemme stop here and catch my breath for a second) ... you
must precede the quote mark with a backslash, thus:

\"

A quote mark to be dealt with as literal text does *not* always
have to be "escaped" that way. This works fine in a script file:

s/"Hello, there"/"HELLO, THERE"/g

On the DOS command line it would have to be done as follows:

"s/\"Hello, there\"/\"HELLO, THERE\"/g"

That's messier than my apartment! Given the choice, then, I would
prefer to use a script file if there are double quote marks to be
dealt with as string literals.


HIGHBIT CHARACTERS IN SCRIPT FILES:

If you are using a program like LIST.COM to view this file, you
will, below, see the IBM-character-set symbols for "1/2" and
"1/4" (ASCII decimal values of 171 and 172, respectively). If you
are viewing the file some other way, you might not see the
characters; if you are printing the file using a printer which
can't display "highbit" characters, you won't see them in the
printout, either.

Suppose this line appears in your input file:

Hello, this is a «-baked "«" character.

The following SED editng instruction would work fine in a script
file or on the command line:

s/«/XXX/g

The result would be:

Hello, this is a XXX-baked XXX character.

However, the following would NOT work either in a script file OR
on the command line:






File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 5





s/«/¬/g

Why? SED, for whatever reason, will strip the highbit character
down to its "lowbit" equivalent when it appears on the "replace-
with" side of a substitution command. The goal would be to change
the line as follows:

Hello, this is a ¬-baked ¬ character.

But SED willl strip the "¬" down to its "lowbit" equivalent of
"," (comma):

Hello, this is a ,-baked , character

Irritating. There is a way around this kind of limitation if you
need to move, or add more of, the searched-for highbit character.
You could use the \( \) construction to put that character into a
numbered memory buffer, then refer to it on the replace-with side
of the command:

s/this is a \(«\) character/this \1 character is ridiculous/g

See the REGEXP.1 file for more about the \( \) construction.

It works, but it's very restrictive. Perhaps there is some way
successfully to enter any "highbit" characters into the replace-
with side of a SED substitution command. If and when I figure it
out, I'll include it in an update of this documentation.

The above is true for the SED version included with this archive.
With the GNU version I have tried, you can give a command like:

s/«/¬/

at the DOS prompt, and it will work; but if you put the command
into a script file, GNU's SED will exhibit the same bug (or could
it be an "undocumented feature"?).


ORDER OF PROCESSING

As far as I have been able to tell, SED reads through a script
file and processes instructions in the exact order they appear
there. Suppose you have a file which has lots of problems with
extra spaces. You want to change the extra spaces in a particular
order - first, you want to remove all occurrences of three or more
spaces and change them to a single TAB character (which I will
represent in the following example with ""). Then, you want
to remove ALL remaining occurrences of two spaces, changing them
to one space alone:





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 6





s/ \{3,\}//g
s/ / /g

(Remember that the "iteration" command shown above will not work
in all versions of SED that you might use.)

SED will process the "three or more" instruction first, *then* go
on to process the "two - change 'em to one" instruction. This way
you can be assured that only when the first instruction has been
executed will the second one be carried out.

An absurd - but workable - example to demonstrate the order of
processing:

s/e/XXX/g
s/XXX/e/g

First you tell SED to replace all occurrences of lower-case "e"
with the character string "XXX" - then you turn around and tell
it to replace all occurrences of "XXX" with lower-case "e". It
works - try it. It would also work on the command line, thus:

sed -e s/e/XXX/g -e s/XXX/e/g

The reason is, again, that SED will execute all instructions, in
order, on the *current* line - until there are no more instructions
to be carried out there. Then and only then will it go on to the
next line.


"t" - "LOOPING" WITHIN SCRIPT FILES

You can put a label into a script file and tell SED via the "t"
command to loop back to that label - *if* any changes were made via
the instruction just below the label. When no more changes can be
made, the looping will stop and SED will go on to the next
instruction. Example:

s/hello/goodbye/
:garbage
s/garbage/junk/
t garbage

The "t," then, is similar to the GOTO instruction used in DOS
batch files. As with DOS batch files, the label name begins with
a colon.

*** IMPORTANT: the "t" must be lower case. The label name
itself can be only seven characters long - that is, a total of 8
characters including the colon. Be sure to match the case of the





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 7




letters in the label name *exactly* when you give the "t" command.
If the "goto label" line reads: t Garbage or t GARBAGE but
the label itself is all lower case, SED will bomb out with an
error message ("undefined label").

You can omit the space between the "t" and the label name if you
wish. So a line reading: tgarbage would work fine. This might
not be true for all SED versions, though.

NOTE: some versions of SED require that you put a space between
the colon and the label name. The version enclosed with this
documentation doesn't seem to care one way or the other about the
space (thus a space is not counted when SED evaluates whether or
not the label name is too long).

Looping is the way to get around a problem with, say, certain GNU
versions of SED - the ones with the bug whereby the "g" modifier
and the "-g" command switch don't work.

Let's go back to the example of dealing with multiple spaces
(three or more - replace them with a single TAB character) and
then to kill all other occurrences of two spaces in a row. This
script file would do the job:

:loop1
s/ +//
t loop1

:loop2
s/ / /
t loop2

(I have used "" above where, in the actual script file,
there would be an actual TAB character.)

You said in the first instruction: search for two spaces followed
by one space. But you have added the "+" character, to mean "one
or more occurrences." So it means: two spaces followed by one or
more spaces - in effect: "three or more spaces." The ONLY string
of text matching the criteria would be three or more spaces in a
row. The "t" command tells SED to keep executing the instruction
on the current input line until there are no more strings
matching the criterion "two spaces followed by one or more
spaces."

The second instruction says: "Search for two spaces and replace
them with one. If the replacement occurred once on the input
line, repeat the subsitution on the same line until there are no
more occurrences of two spaces in a row."

(There's more about the use of the "+" character in the file
REGEXP.1.)




File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 8






The above is workable, but it's a little klutzy to have to
write out.

*** IMPORTANT NOTE: the version of SED included with this
archive contains a bug whereby script file commands that use "+"
might not work properly. Well, it's a good deal the program
supports iteration commands. You can use a previously cited way
to *specify* the number of spaces to search for:

s/ \{3,\}//g
s/ / /g

That's much more precise. Bugs or no bugs in this version of
SED.EXE, I much prefer to give the instruction as shown, anyway.


"a" - APPEND TEXT FOLLOWING A GIVEN LINE

The "a" command (once again: must be lower case) in a script file
tells SED to append text at a specific line - that is, to insert
a new line of text, and a line boundary (CR plus LF) at the end
of the new text, *below* the line you specify.

Not specifying any line at all results in the new text's being
inserted below EVERY line - probably not what you want, eh?

The "a" command, like the "i" command (see below) has a peculiar
syntax of its own. You don't just type "a" in the script file,
but rather:

a\

Right. A backslash follows the "a." I suppose this is to tell SED
there's more coming on the next line - a continuation of the "a"
command.

a\
HELLO

You didn't tell SED which line to look for. So it will add
"HELLO," on its own line, below EVERY line in the file, including
below any and all blank lines.

If this is the input file:

Here is the first line
Here is the second line
The next line is blank
This is the last line.





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 9






then the "a" command just shown would result in:

Here is the first line
HELLO
Here is the second line
HELLO
The next line is blank
HELLO

HELLO
This is the last line.
HELLO

The instruction:

2a\
HELLO

would tell SED to add a line reading "HELLO" below line 2 of the
input file. Result:

Here is the first line
Here is the second line
HELLO
The next line is blank

This is the last line.

The instruction:

8 a\
HELLO

would tell SED to add a line reading "HELLO" below the 8th line
of the input file. Note how there's no space between "2" and "a\"
in the second-to-last example, and there is a space between "8"
and "a\" in the very last example. No big deal: doesn't make any
difference if you include the space or not.

$ a\
HELLO

would tell SED to add a line reading "HELLO" below the LAST line
of the input file.

/Whatever/ a\
HELLO

would tell SED to add a line reading "HELLO" below any line
containing the character string "Whatever" (remember, SED is




File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 10





case-sensitive). You could defeat that - if you wanted it to find
either "Whatever" *or* "whatever," as follows:

/[Ww]hatever/ a\
HELLO

(If you haven't already read about the [ ] construction, see
the file REGEXP.1.)

Other ways of writing out a regular expression apply here, too:

/^Whatever/ a\
HELLO

would restrict the addition of the line reading "HELLO" - the new
text would be added *only* below a line which *begins* with
"Whatever."

/I'm outta here\.$/ a\
Oh no you're not.

would add a line reading "Oh no you're not." - but *only* following
a line which *ends* with the character string "I'm outta here." -
due to the use of the $ character in the expression. (The
string: \. forces SED to look for a period; otherwise, it would
look for "I'm outta here" followed by *any* character - and then
the end of the line.

You've noticed by now that, as with other SED commands, when you
are using the "a" command and are specifying a line by reference
to text within it, you bracket the expression with /
characters. If you're specifying the line by reference only to
its number (or via the $ character), you do not surround the
"address" with / characters.

Wrong: /8/ a\
(unless you're telling SED to find a line with "8" in it)

Right: 8 a\


Wrong: Below this text a\

Right: /Below this text/ a\

What if you want to add the text only below *blank* lines? Use
SED's way of saying "blank line":

/^$/ a\
HELLO





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 11





Can you tell SED insert specific text below lines, restricting
the insertions to a given RANGE of lines? As in: 3,6 a\ ?

*NO.* For whatever reason, the version of SED included with these
docs won't support that kind of "address" specification. Sorry.
(Wait a minute. What the devil am *I* apologizing for? I didn't
write the silly program.)

But here is where the { } construction, mentioned above, comes
in handy:

1,20{
a\
HELLO
}

Would operate on lines 1 through 20, executing the "a" command
properly within that range.

Are you limited to the insertion of only one line of new text?
No. You keep using the \ character in the script file to tell
SED to keep inserting text.

1 a\
HELLO\
GOODBYE
s/yes/no/g

The \ character following "HELLO" tells SED to read the very
next line in the script file ("GOODBYE"), inserting *that* line
following "HELLO." How does SED know when to stop appending text?
It will not add the string "s/yes/no/g" (below "GOODBYE") because
"GOODBYE" does not end in a backslash. In other words: whatever
follows a line ending with a backslash is a continuation of the
"append" command. That also goes for adding new blank lines:

5 a\
HELLO\

s/yes/no/g

would add "HELLO" on its own line below line 5 of the input file,
then add a blank line below the new line with "HELLO" on it. It
would *not* add the string "s/yes/no/g" to the input file. But if
the instruction had looked like this:

5 a\
HELLO\
\
s/yes/no/g





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 12





then SED would have added, below line 5, a line reading "HELLO,"
then a blank line, and then text reading "s/yes/no/g" (in which
case, SED would have not have executed "s/yes/no/g" as an editing
instruction).

A command like:

/Whatever/ a\

[some other editing command here]

would add a blank line below any line containing the string
"Whatever." Nothing which followed the blank line in the script
file would be added to the input file. A command like this:

a\

[some other editing command here]

would add a blank line below *every* line in the file - the
functional equivalent of a command discussed in my main SED
documentation file:

sed G inputfile

This instruction:

a\
\

[some other editing command here]

would add two blank lines below every line in the file.

A rule you've seen in the discussion of substitution commands
also applies to the "append" command: new text to be added, like
the text on the "replace-with" side of a s/ command, should *not*
be put in the form of a regular expression. So just as:

s/[Ww]hatever/[Dd]oesn't matter/g

won't get you what you want, neither will an instruction like
this:

/[Ww]hatever/ a\
[Nn]ew text here.

As noted above (under "Nesting Commands") SED will normally strip
out any leading spaces or TABs in script files (meaning: those
which precede an editing instruction in the script). However, in





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 13




certain commands ("a," "i," and "c") SED will *not* ignore leading
spaces. In an instruction like:

2 a\
HERE IS THE NEW TEXT

SED would add: " HERE IS THE NEW TEXT" below line 2. If the
input file looked like this:

Line one
Line two
Line three

after the above "a" command it would look like this:

Line one
Line two
HERE IS THE NEW TEXT
Line three



"i" - INSERT TEXT ABOVE A GIVEN LINE

The "i" command (as always : lower case only) inserts text
*above* a specified line in the input file.

All of the rules for the "a" command apply equally to the "i"
command. That was easy, wasn't it?

And, since you asked: yes, you can certainly insert new text,
including blank lines, above the *first* line of an input file.

Here is a practical example: suppose you have some program that
writes a plain text file to disk - a log of its activities. For
some reason the program doesn't date-stamp the file. You want
that date stamp, and you want it at the *top* of the file.

Ok, we'll suppose you've already created an environment variable
called DATE and it contains the string "January 1, 1990." Now, in
a batch file:

echo 1i\ > script.tmp
:: echo string "1i\" & redirect it to a new file,
:: SCRIPT.TMP

echo %DATE% >> script.tmp
:: echo contents of the "DATE" variable, *appending*
:: the information to SCRIPT.TMP.

echo.>> script.tmp [ continues, next page ]





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 14




echo.>> script.tmp
:: append a blank line to SCRIPT.TMP, then another
:: to ensure there is a line-ending character after
:: the last instruction. SCRIPT.TMP now looks like this:

:: 1i\
:: January 1, 1990
:: (blank line here)

:: Next, run SED:
type logfile | sed -f script.tmp > logfile

:: types LOGFILE, pipes its output to SED, which then
:: inserts the date information on its own line above
:: the original line 1 of LOGFILE - then overwrites
:: LOGFILE.

There are, of course, other ways to do the same thing via batch
files, but there you have it.


"r" - READ FROM AN EXISTING FILE

The "r" command will cause SED to insert into the input file the
contents of a file already on disk. The inserted text will always
be placed *below* the line you identify for SED via a line number,
string literal, or regular expression. Be careful - an
instruction like this:

r new.doc

would insert NEW.DOC below *every* line in the input file (probably
not what you want at all - especially not if NEW.DOC is 50,000
bytes long).

4r new.doc (or: 4 r new.doc)

would insert the contents of NEW.DOC below line four of the
input file.

The following command is illegal:

4,7 r new.doc

SED supports only a *single* address in the "read file"
instruction, but you could, again, use a "nesting" procedure:

4,7{
r new.doc
}






File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 15




SED doesn't care if the command take the form "4r new.doc" or
"4 r new.doc", but note:

6rnew.doc

would be illegal. Put at least one space between the "r" and
the file name.

/below this line/ r new.doc

would tell SED to find lines containing the string "below this
line" and insert the entire contents of NEW.DOC below and and all
such lines.

/^$/ r new.doc

would tell SED to insert the contents of NEW.DOC beginning below
any and all blank lines in the file.

You can certainly include path information in the name of the
file to be inserted, but there is a catch. The following works
just fine:

4r d:\new.doc

The following does *not* work:

4r d:\text\new.doc

Nothing happens at all when the instruction takes that form. At
first I thought it was a bug only in the version of SED that I
use most often (the one which comes with this documentation) but
then I found GNU's version of SED has the same problem. Misery
loves company, eh? The workaround is:

4r d:\\text\\new.doc

"Huh?" you ask. Yeah, good question. But there you have it; it
works.


"c" - CHANGE LINES

Right. You've been noticing the commands aren't discussed in
alphabetical order. Sorry. Moving right along ...

The "c" command alters lines by completely replacing them with
other text. The command takes this form:

[address] c\
new text





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 16




where "[address]" is replaced by the various ways of telling SED
how to locate lines in a file.

4 c\
new text

would replace line 4 in its *entirety* with a line reading "new
text." The line boundary at the end of line 4 would remain
intact.

3,10 c\
new text

would replace lines 3 through and including 10 with "new text." I
mean to say: line 3 through/including 10 would be deleted and
replaced by the *single* line reading "new text."

If the input file looks like this:

Line one.
Line two.
Line three.
Line four.
Line five.

and the script file instruction looks like this:

2,4c\
THIS IS THE NEW TEXT

The result is:

Line one.
THIS IS THE NEW TEXT
Line five.

The instruction:

/change this line/ c\
new text

would find all lines containing the words "change this text" and
replace them, again in their entirety, with "new text."

/change this line/,/more changes here/ c\
new text

would tell SED to change a certain range of lines only, beginning
with one containing "change this line" down through and
including - and no farther than - one containing "more changes
here."





File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 17





*** Caution: if text you specify as the ending-point does not
exist, SED will quite happily kill all lines in the file,
beginning with the first "address," and replace all of the
deleted lines with the replacement text.

This is not a problem if it doesn't find the *first* text you've
specified - in that case you have a different sort of problem on
your hands: it won't do anything at all to the file.

As with the "a" and "i" commands, you continue the text to be
added by ending a line of new text with a backslash.

4,6 c\
ADD THIS LINE TO THE TEXT.\
AND ADD THIS LINE AS WELL.
s/DON'T ADD THIS LINE, HOWEVER./xxxxx/g

would remove lines 4 and 6, replacing them with, first, the line
reading "ADD THIS LINE TO THE TEXT." followed by a line boundary
and then the line reading "AND ADD THIS LINE AS WELL." The next
line - a substitution command - would be treated as an editing
instruction, not as more text to be added.

To replace the specified lines with *nothing* (nothing other than
a line boundary, that is:

4,6 c\

with no text after it. This could be troublesome if you would
like to have some other instruction following the "c" command,
but you don't want the instruction to be treated as text to be
inserted. The way around it is to ensure there is a blank line
between the line containing "c\" and the next instruction:

/hello/c\

s/yes, you bet/no way, fellah/g

That command is the functional equivalent of:

/hello/ s/^.*$//

(which says: On any line containing "hello," find the beginning
of the line, followed by any number of any character - i.e.,
"everything on the line", then the end of the line, and replace
all characters on the line with *nothing*. The line boundary will
remain intact).







File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 18



By itself:

c\

alone in a script file would kill *every* line in the file (no
"address" specified), leaving only the line boundaries. So by
itself like that, "c" is NOT the same as the "d" command, which
kills not just the text on a line but also the line boundary
itself. In other words, "c" will leave *at least one* line boundary
intact when you tell it to replace a range of lines.

As with the "a" and "i" commands, SED will not strip out leading
spaces or TABs in the replacement text of a "c" command.


Ok - there is the just about the sum total of what I know about
SED script files. Believe me, there is a lot more to know about
them. If you thought all of the above was verbose, wait until I
learn *everything.* Then you're in for it.

It is disappointing not to be able to include information about
such operators as "g" "G" "h" "H", and so on. They manipulate the
work and hold spaces and must surely provide tremendous
additional power to SED. At the least there's some useful
information in these docs about the "N" command - see the file
SFILES-B.1. More about "g" and company in a future version of
this file, I hope.


( E N D )



























File SFILES-A.1 - about SED - Copyright 1990 Mike Arst Page: 19