ssd@sugar.uu.net (Scott Denham) (11/25/88)
I know there has been some recent discussion of ARexx and the current
path and directory assignments, but I think I must have missed something.
Apparently DOS commands run from an ARexx script inherit the "default"
settings for both the path and the current directory - but the work-
around I thought should have worked doesn't seem to. Rather than, say
'delete ram:temp' with ram:c at the head of the path string, I used
'ram:c/delete ram:temp', etc. I still get the blasted requestor to re-
insert the workbench disk I bted from. It seems to all come down to
the C: pseudo-device; if I assign C: to RAM:C, evething works as I
would have expected. If I assign C: to RAM:, the script runs but does
not invoke any of the commands in it, even though they all contain
explicit paths (I.E. SYS1:bin/cc ...) Anyone know whaC: is being
accessed for here ??? Will I be horribly embarassed when I wake up in
the morning and discover I missed something obvious in my turkey-induced
stupor ????
Scott Denham riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (11/26/88)
In article <3015@sugar.uu.net> ssd@sugar.uu.net (Scott Denham) writes about problems invoking AmigaDOS commands from an ARexx script. He writes: >Rather than, say >'delete ram:temp' with ram:c at the head of the path string, I used >'ram:c/delete ram:temp', etc. I still get the blasted requestor to re- >insert the workbench disk I booted from. It seems to all come down to >the C: pseudo-device; if I assign C: to RAM:C, evething works as I >would have expected. If I assign C: to RAM:, the script runs but does >not invoke any of the commands in it, even though they all contain >explicit paths (I.E. SYS1:bin/cc ...) This is a good candidate for the "answers to the most commonly asked Amiga questions" collection. For compatibility reasons, most programs which expect to spawn off arbitrary AmigaDOS commands use the AmigaDOS Execute() function. Execute() needs c:run to do it's magic. If c: isn't currently mounted, it asks for it. If run isn't in c:, Execute() fails. [I usually just mail off answers to this kind of problem, but I've seen essentially the same problem in slightly different contexts enough times this month to warrant a posting] -Dan Riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet) -Wilson Lab, Cornell U.