Category : Word Processors
Archive   : USEDI.ZIP
Filename : MORE-SED.INF

File: MORE-SED.INF - part of the U-SEDIT1.ZIP archive.
Copyright 1990 Mike Arst
This text added January 20, 1990


I found out a few interesting things about SED only *after* I had
finished writing the main parts of the documentation.

There is a kind of wildcard you can use on the "search-for" side of
a substitution command; if I'd only listened to my original SED
advisor, Tim Evans, I'd-a remembered about it.

Suppose you need to identify specific lines for SED so that it will
execute a substitution only on those lines. You might do it like
this:

/^[Hh][Ee]llo \{3,\}/ s/^[Hh][Ee]llo \{3,\}/new text here/

Yet another silly example, but what's not silly is that you often
end up writing moderately involved regular expressions for SED to
process. The above is a nuisance. You have to type out the regular
expression twice.

Oh, no you don't. You can abbreviate it like this:

/^[Hh][Ee]llo \{3,\}/ s//new text here/

Instead of retyping it within the "search-for" side of the
substitution instruction, simply put two / characters together as
shown in the second example. Of course, "//" on the "replace-with"
side would mean "delete the string just found." Well, variety is
the spice of life, eh?

You can use this abbreviation in script files as well. Suppose you
want to find "hello" and replace it with "goodbye". The script file
instruction could look like this:

hello/ {
s//goodbye/g
}

That's not an instance in which there is any benefit to using this
method of writing the instruction, but you should be aware that it
is supported within script files.


JUST SAY NO within script files:

Imagine my surprise when I discovered:

/hello/ !{
instruction
instruction
instruction
}

In other words: EXCEPT on a line containing "hello," execute the
following instructions. In other words, the "!" operator - meaning
"not" - is usable within a "nesting" construction.

It got even more interesting:

What if you want to execute a certain command but you wish to
exclude certain lines - but the normal "not" sort of instruction
stands to cause the command to be executed on *other* lines that you
cannot specify in the first instruction? Answer: oh, yes, you CAN
specify them (damn. If I were only a C programmer, I'd probably have
figured this one out right at the beginning):

/^Hello/ !{
/^$/ !{
s/yes/no/g
}
}

In other words: "EXCEPT on a line that begins with "Hello" - but
wait, there's more! - ALSO EXCEPT on a *blank* line ... execute
such-and-such an instruction."

The substitution would be performed NEITHER on lines beginning
"Hello" NOR on blank lines. This is especially useful if you have a
command which places new text at the beginning of lines but you sure
don't want lines that are now blank to have extraneous text on them.
Pretty nifty ...

Remember: you have to ensure that the number of { (begin
construction) characters matches the number of } (end construction)
characters. Otherwise, SED will bomb out with one of its cheery
little error messages.

No, I don't know how many levels deep this nesting can occur. I
shoulda checked it out, but I didn't. Shame on me.


In the main files, I should have - and didn't - say more about how
text is added to the beginnings and endings of lines.

5s/^/Hello/

would add "Hello" to the beginning of line 5.

/^Goodbye/ s/^/Hello and /

would add "Hello and" followed by a space to the beginning of each
line which begins with "goodbye."

s/$/new text/

would add "new text" to the end of each line. The line boundary
itself would not be altered. The "$" sign, itself, makes it very
clear that the new text should be added at the end of *ALL OTHER*
text on the line, no matter what it is.


A final suggestion: on occasion you'll give SED some kind of funky
instruction and the instruction will fail. There'll be a delay
during processing, and then you'll see the DOS prompt. There won't
have been any display. If you used the "-n" switch, you have no one
but yourself to blame, of course - but what if you didn't use it?
If such a thing happens, consider "piping" SED's output to the file
viewer LIST.COM (remember to use LIST's "/s" switch).

When the output - appearing to contain nothing at all - is on the
LIST screen, press ALT H to switch to a view in hexadecimal. What
this will get you is a display of the line ending characters (to
the right of the display). Ordinarily they wouldn't be visible on
the screen.

It's a handy way to check: did SED kill ALL of the lines in the
file? No? Did it write a few *blank* lines? If so, how many? What
really happened during processing.

LIST's "hex view" mode is also a good way to check if a file
contains carriage-return characters at the ends of lines, but no
line feed characters. If that is the case, no wonder SED failed!
Time to run a program like CHG.EXE, and re-establish the line
feeds following the carriage returns.

Once in a while you get a file to process in which some program
has munged up the line endings. If you use TYPE to view the file
on the screen, it'll look fine. But there will actually be in it
conventional line endings (CTRL M CTRL J) *followed* by isolated
CTRL Ms.

SED will, guaranteed, spit up on those isolated carriage returns.
It will not process your file. It will print it to the screen,
but your substitution commands (or whatever) won't get carried
out. Or rather, sometimes they will, and sometimes they won't.
So make sure the line endings are all right before running SED on
a file - and be very sure they're ok if you plan to over-write
the source file during processing.

(E N D)