mjp@spice.cs.cmu.edu (Michael Portuesi) (07/31/87)
Keywords:
I decided to experiment with AmigaDOS script-hacking, just to see how
far I could push it. Often, I download software from Usenet or other
places in big batches and place it in subdirectories on a disk. It
would be nice if I could run a command from the root directory on
every file that matched a pattern anywhere on disk, much like the ALL
keyword for COPY and DELETE. This way, I could un-shar every .sh file
on a disk with just one command, e.g.
EXECUTE apply "shar -u $name" #?.sh
Armed with the AmigaDOS manual, I began my task. Realizing that
AmigaDOS does not allow iteration over the results of a command, like
the "foreach" statement in csh, I opted to direct the output of DIR to
a file and run it through EDIT to create a file of executable commands
that I would EXECUTE.
DIR, while offering an option to do a recursive directory list, also
outputs its information in a two-column format that is impossible to
parse with EDIT. LIST, while offering a listing that is easily
interpreted by other programs, does not offer a recursive directory
search. Grrr.
So I decided to use DIR to list just the subdirectories of the current
directory to a file. Then I would run that through EDIT to create a
batch of LIST commands that would generate all the file names, plus
instructions to concatenate those into one big file. This file would
be run through EDIT once again to create the executable commands, and
then executed. It is easy to run EDIT in batch mode. It is easy to
use ECHO to create a command file for EDIT. But when the necessary
commands for EDIT exceed one line, you're hosed because ECHO can only
handle one line of input, and AmigaDOS doesn't know how to redirect
output by appending to the end of a file!
So what have I learned from this?
1) The CLI and the EXECUTE command are unsuitable for
general-purpose shell hacking.
2) The AmigaDOS commands weren't written with batch processing
of any type in mind.
3) Not only is EDIT a lose as an interactive line editor, it
is also a very bad stream editor.
4) I'll try this again with Matt's Shell at the earliest
opportunity.
--
Mike Portuesi / Carnegie-Mellon University Computer Science Department
ARPA: mjp@spice.cs.cmu.edu UUCP: {backbone-site}!spice.cs.cmu.edu!mjp
BITNET: rainwalker@drycas (a uVax-1 run by CMU Computer Club...tons o' fun)
"Paradise is exactly like where you are right now...only much, much better"
--Laurie Anderson, "Lanugage is a Virus"mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (07/31/87)
In article <1249@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) writes:
<DIR, while offering an option to do a recursive directory list, also
<outputs its information in a two-column format that is impossible to
<parse with EDIT. LIST, while offering a listing that is easily
<interpreted by other programs, does not offer a recursive directory
<search. Grrr.
I had similar problems. LIST gives me tabs, but SORT didn't believe in
them, and would only sort on a specific *character* column. So I wrote
a quickie detaber. No biggie.
<It is easy to run EDIT in batch mode. It is easy to
<use ECHO to create a command file for EDIT. But when the necessary
<commands for EDIT exceed one line, you're hosed because ECHO can only
<handle one line of input, and AmigaDOS doesn't know how to redirect
<output by appending to the end of a file!
Uh, I didn't have that kind of problem. Then again, I didn't try to
make echo do something it wasn't intended to do. I used edit to create
the multi-line edit script. Worked like a charm.
< 1) The CLI and the EXECUTE command are unsuitable for
< general-purpose shell hacking.
<
< 2) The AmigaDOS commands weren't written with batch processing
< of any type in mind.
True. Something that those writing replacements need to consider.
< 3) Not only is EDIT a lose as an interactive line editor, it
< is also a very bad stream editor.
I don't agree. Edit is a *far* better stream editor than Unix ed. For
anything complicated, it's better than sed. The builtin ability
to loop, as opposed to the "all commands on every line" of sed is a
win. [Warning: the abilities of awk have kept me from really learning
the magic of sed.] Edit isn't an awk, but it's fairly powerfull.
< 4) I'll try this again with Matt's Shell at the earliest
< opportunity.
Also make *sure* you've got a pipe: driver. Things run a *lot* faster
with it. You can get one from MetaComCo, Matt has one that's PD, and
Ed Puckett has one that includes a nifty feature called "taps" which
let you look at what's going through the pipe (among other things).
The last showed up on the net, and is the one I'd recommend.
<mike
--
Must have walked those streets for hours, Mike Meyer
In the dark and in the cold, mwm@berkeley.edu
Before I really could accept, ucbvax!mwm
There's no place called hope road. mwm@ucbjade.BITNETmjp@spice.cs.cmu.edu (Michael Portuesi) (07/31/87)
Keywords: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: > I had similar problems. LIST gives me tabs, but SORT didn't believe in > them, and would only sort on a specific *character* column. So I wrote > a quickie detaber. No biggie. > Uh, I didn't have that kind of problem. Then again, I didn't try to > make echo do something it wasn't intended to do. I used edit to create > the multi-line edit script. Worked like a charm. I yanked those two out quotes of context, but for my purpose it doesn't matter. My goal was to create a self-contained CLI script that could do its work without external files or programs that I had written. All I wanted to depend on was the stuff that came with the Workbench disk. (Remember, this was half experiment, half practical idea). Is there a way to make EDIT create a multi-line edit script without using an external file? Could you illustrate? BTW, "intending" a command to be used for a specific purpose merely cuts down on the utility of the system as a whole, as it limits the way individual pieces can be combined. > I don't agree. Edit is a *far* better stream editor than Unix ed. For > anything complicated, it's better than sed. The builtin ability > to loop, as opposed to the "all commands on every line" of sed is a > win. [Warning: the abilities of awk have kept me from really learning > the magic of sed.] Edit isn't an awk, but it's fairly powerfull. Okay, the ability to loop a sequence of instructions is a big win in EDIT. But a few things I could wish for are: * The ability to search for *expressions*, rather than character strings * Some sort of temporary storage, analogous to the TECO Q-register, that can be used to hold text or other information * The ability to use text extracted from the current line as a parameter for a subsequent command. Temporary storage can be simulated using temporary files (thank GOD for ramdisks), but there is no way to emulate this feature with EDIT (well, maybe there is, but it's complicated enough to be not worth the trouble) > Also make *sure* you've got a pipe: driver. Thanks for the advice. If something useful comes of this, I'll share it with everyone. --M -- Mike Portuesi / Carnegie-Mellon University Computer Science Department ARPA: mjp@spice.cs.cmu.edu UUCP: {backbone-site}!spice.cs.cmu.edu!mjp BITNET: rainwalker@drycas (a uVax-1 run by CMU Computer Club...tons o' fun) "Paradise is exactly like where you are right now...only much, much better" --Laurie Anderson, "Lanugage is a Virus"
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (08/03/87)
In article <1251@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) writes:
<doesn't matter. My goal was to create a self-contained CLI script
<that could do its work without external files or programs that I had
<written.
That constraint makes things *much* harder! I use edit scripts with
great abandon.
<All I wanted to depend on was the stuff that came with the
<Workbench disk. (Remember, this was half experiment, half practical
<idea). Is there a way to make EDIT create a multi-line edit script
<without using an external file? Could you illustrate?
Hmm. Not sure it can be done. But your original need (wanting a ">>")
can be done with temp files. To wit:
echo >ram:temp1 hello
echo >ram:temp2 there
join ram:temp1 ram:temp2 as output-file
<BTW, "intending" a command to be used for a specific purpose merely
<cuts down on the utility of the system as a whole, as it limits the
<way individual pieces can be combined.
True. I'm always pleased when I find people using the tools I created
in ways I never intended them to be used.
<Okay, the ability to loop a sequence of instructions is a big win in
<EDIT. But a few things I could wish for are:
<
< * Some sort of temporary storage, analogous to the TECO
< Q-register, that can be used to hold text or other
< information
Here we are, playing with popguns (ed, sed, edit) and he pulls out a
tac nuke (teco) :-). Why don't you just do your stream editing with
GNU emacs? After all, it's got all of these things, and more.... :-)
< * The ability to use text extracted from the current line as
< a parameter for a subsequent command. Temporary storage can
< be simulated using temporary files (thank GOD for ramdisks),
< but there is no way to emulate this feature with EDIT (well,
< maybe there is, but it's complicated enough to be not worth
< the trouble)
I didn't have any troubles simulating (part of) this with ramdisks.
The trick is to run edit over the file multiple times - the first time
you create an edit script to be used for the second time. I didn't do
this exactly, but did similar things (edit one file into an edit
command file for a second file).
For some *really* spiffy script capabilities, find the article
describing ksh-i. It turns parenthesized command strings in the
argument list into a file name, after mapping the output from that
string into a pipe fd. So things like:
Gen-strings > /tmp/my-strings
awk <more-strings> | fgrep -f /tmp/my-strings
Get turned into:
fgrep -f (Gen-strings) (awk <more-strings)
And more uses will turn up as time goes on, I'm sure....
<mike
--
Must have walked those streets for hours, Mike Meyer
In the dark and in the cold, mwm@berkeley.edu
Before I really could accept, ucbvax!mwm
There's no place called hope road. mwm@ucbjade.BITNETfarren@hoptoad.uucp (Mike Farren) (08/03/87)
In article <4560@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >Here we are, playing with popguns (ed, sed, edit) and he pulls out a >tac nuke (teco) :-). Why don't you just do your stream editing with >GNU emacs? After all, it's got all of these things, and more.... :-) So - he pulls out a tactical nuke, and you respond with a 100 Megaton thermonuclear device? I think I've seen this pattern before... -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"