Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!midway!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.editors
Subject: Re: sed output
Message-ID: <1991Mar01.202635.8827@chinet.chi.il.us>
Date: 1 Mar 91 20:26:35 GMT
References: <1991Feb20.234921.5738@ddsw1.MCS.COM> <1991Feb25.184548.14778@chinet.chi.il.us> <1991Feb27.172236.7202@ddsw1.MCS.COM>
Organization: Chinet - Chicago Public Access UNIX
Lines: 82

In article <1991Feb27.172236.7202@ddsw1.MCS.COM> dattier@ddsw1.MCS.COM (David W. Tamkin) writes:
[about perl]
>Yes, I knew that.  It probably doesn't take all that many forks of smaller
>programs before there's more overhead than for one fork of perl.  Are you
>volunteering to teach me, Les?  You know where I live.

I'm hardly an expert.  I just get by with two terminals on my desk so
when I get stuck I can experiment on the 2nd one without losing my
place in the problem.  Perl has the great advantage of having a usable
debugger as opposed to sed's "garbled command" or awk's "bailing out
near line _" error message (singular).  I don't object to questions
by email but I can't guarantee how long it will take to respond...

[use ex instead]
>That's not so simple for this application.  There are a number of things I'm
>doing in the sed script that would be really bearish in ex;

On the contrary - ex handles them just fine.  Sed just barely does them.

>the first that
>comes to mind is how to resume the editing from the beginning when the next
>input file is ready.  (Surely I shouldn't have to change the script to have N
>copies of itself when the input contains N files.) 

With ex, you must use an explicit 'n' to go to the next file so you know
when it is going to happen.  Duplicating the command script is trivial
once you have it right and you can carry text between files in the
named registers.  Back in the days before perl I would have done something
like this by having the shell generate the ex script with the proper
number of iterations, then execute it.  Since your main script can source
another file it can just consist of:
so real_script
n!
so real_script
...

>That brings us back to
>having the shell, not the editor, do the cycling and thus forking the editor
>again and again.

That's pretty reasonable too, given ex's ability to w >>file (remember the
original problem).  Note that the file has to exist or the >> will fail
but you can let the shell create an empty file to start.

>The second is that one thing I'm doing involves handling
>the case of a pattern that doesn't show up by h'ing it when it arrives and
>then, after its last chance to appear, g'ing and checking for its presence. 
>In ex I'd have to do a pattern search for it, and if it isn't there, the ex
>script will break; moreover, if I am trying to ex the entire input in one
>fork, a pattern search while I'm working on a portion that is missing the
>pattern will land on its occurrence in another portion, and then KABOOM.

Use the address,addresscommand form instead of separate search, command.
Note that address can be a line number or a search pattern.
Example:
/foo/d a
(delete line containing pattern foo into register a)
0 put a
(put register a before the first line)
/start/,/end/d b
(delete line containing pattern "start" through line containing "end" to
 register b)
/foo/put b
(put register b after line containing pattern foo)

The problem remains of failing pattern matches terminating the script
(likewise for attempting to put registers with nothing in them).
The only solution I've found is that you can source another file, and
a failure will only terminate the file being sourced, allowing the
next level up script to continue.  I suppose you could get a crude form of
flow control out of this, but it seems like there should be a settable
option to prevent aborting on errors.

>This is the sort of thing that awk and perl are for.  I'm trying to cut down
>a sapling with a carving knife.  It's better than a butterknife, and I don't
>need a chainsaw, but a regular saw would be very nice to have use of.

Ex is pretty regular.  The standard documentation doesn't begin to cover
it, though.

Les Mikesell
  les@chinet.chi.il.us