1) Isolate a regex-specified (and probably multi-line) subset from
file.txt as discrete records for---
2) Interactive editing
3) Remerge each of those records in order back to their original
locations in the original file.
My best guess is to do a global writing-out loop with ed to a lookup
table, edit that table, then remerge with awk:
$ ed file.txt
g/regex/.;/record_end_regex/.w !cat >>file_subset.txt
g/regex/.;/record_end_regex/c\
SUBSET_ORIGINALLY_HERE\
/
w
q
$ e file_subset.txt #...
$ awk '/SUBSET_ORIGINALLY_HERE/{ #... }' file.txt
Now, before I waste precious space-time writing this awk script, maybe
some of you who were alive during my current time can point me to an
already existing tool, or at least describe some simple pseudo-code for
the awk script. (Don't worry too much about the version of unix here; I
think I can telnet to other university unix servers and use SYSV tools,
too, for example.)
TIA!
> $ ed file.txt
> g/regex/.;/record_end_regex/.w !cat >>file_subset.txt
> g/regex/.;/record_end_regex/c\
> SUBSET_ORIGINALLY_HERE\
> /
> w
> q
> $ e file_subset.txt #...
> $ awk '/SUBSET_ORIGINALLY_HERE/{ #... }' file.txt
>
> Now, before I waste precious space-time writing this awk script, maybe
> some of you who were alive during my current time can point me to an
> already existing tool, or at least describe some simple pseudo-code
> for the awk script. (Don't worry too much about the version of unix
> here; I think I can telnet to other university unix servers and use
> SYSV tools, too, for example.)
% man sed
--
Edward Dodge
>> $ ed file.txt
>> g/regex/.;/record_end_regex/.w !cat >>file_subset.txt
>> g/regex/.;/record_end_regex/c\
>> SUBSET_ORIGINALLY_HERE\
>> /
>> w
>> q
>> $ e file_subset.txt #...
>> $ awk '/SUBSET_ORIGINALLY_HERE/{ #... }' file.txt
> % man sed
Sorry, I don't see it there.
Getting sed as far as the ed, above, I understand
('H'...'d'...'s'...'w'), but then after the interactive edit of the new
records, how to read each back into the original file at each index (and
in sequence)?
Did you mean, "man sed; man split; man fifo; man sh"?
I strongly advise against having anything to do with sed. Anything you
can do with sed, you can do with AWK (*), so there's really no point in
learning sed.
(*) Pedants may feel obliged to point out:
1) There is probably some exception to this generalization. To that
I say, first, it doesn't matter. In order to find it, you'd
have to get so deep into sed programming that you'd fry your
brain by that time. I.e., I consider sed programming (beyond
the trivial/obvious) to be harmful to one's sanity. Second, the
one primary exception (backreferencing) is handled by using a
modern AWK (e.g., GAWK). True, POSIX AWK doesn't require it,
but so what?
2) Yes, you could also say "Perl" here. Or Python. Or whatever.
But AWK is the easiest to use, and I've always found it to be
the best tradeoff between power and complexity.
You could probably do something like
:g/mypattern/!myprog
where myprog reads stdin, writes that out in a file, edits the file, and
writes out the changed file to stdout again.
If I could do this with sed I would.
Actually I like sed. If I find I've imagined my problem
as a regular expressions problem, then a sed script will
have less procedural hubbub than awk.
On Nov 27, 8:43 pm, yard-ape <yard-...@telus.net> wrote:
> Due to a time-space anomaly I'm trapped in 1986 in the
> UCB comp sci lab. I'm judging the date from the kind of
> text processing tools I can find in this unix terminal in
> front of me.
:-)
> Now, using those tools, how can I implement the following
> workflow (and thus save the planet and escape back to your
> time):
>
> [blah]
It might be better if you told us your problem. We might be
able to come up with a better workflow, or at least
a different one that works as well. --Antony
They had Thunderbird 2.0.0.12 in 1986?
--
David Trimboli
Windows Systems Analyst
Cold Spring Harbor Laboratory
Doh!