| Can't answer your question, but experienced the same problem (as
have others, as you can see be the following USENET extract).
I wrote a quick and dirty AREXX spelling checker for TxEd using
MICROSPELL. MICROSPELL writes a file listing all the words (or
location of the words) contained in the document that it can't
find in its' dictionary. If I run MICROSPELL from the CLI, it
prints the file to the current directory. If I run it from within
AREXX (address command microspell) it writes the file to DF0 -
regardless of my current directory or device.
I called William Hawes and he explained to me that it was a
problem in the operating system and not with AREXX directly. Not
being technically inclined, most of what he said went over my
head - but he wrote AREXX, so who am I to argue with his
explanation.
If there are any AREXX users out there with sufficient technical
knowledge to understand and articulate Hawes' explanation, I would
appreciate if you would give him a call and post a translation.
Thanks
Art
<<< MSBIS::DISK15:[USENET.AMIGA]AMIGA_TECH.NOTE;2 >>>
-< USENET comp.sys.amiga.tech articles >-
================================================================================
Note 349.11 ARexx Questions 11 of 11
MSBIS::LANDINGHAM "cisunx!ejkst" 50 lines 16-NOV-1988 19:13
-< -- Base Item -- >-
--------------------------------------------------------------------------------
Newsgroups: comp.sys.amiga.tech
Path: decwrl!labrea!rutgers!rochester!pt.cs.cmu.edu!cadre!pitt!cisunx!ejkst
Subject: ARexx questions
Posted: 15 Nov 88 20:07:50 GMT
Organization: Univ. of Pittsburgh, Comp & Info Sys
I've got a few ARexx questions.
1. I think I already have an idea what's going on here, but whenever I
"address command 'external command'" something, the results are
frequently disappointing. First of all, it seems ARexx has no idea what
my path is, because it can only find an external program if it's in the
current directory or C:. So unless I put 500 files in one directory, I
must specify the entire path to the program. Second, when the program
is executed, it seems to be executing out of sys:, sometimes, or RAD:, (my boot
device) at others. "address command 'ls'" does *not* give me a
listing of my current directory. (It gives a listing of RAD:. "Address
command 'cd'" prints "sys:" which is on dh0:.) This makes it a little
difficult to use ARexx as a shell scripting language.
Am I right in guessing that this is the same process vs. task problem
that prevents PopCLI III from remembering path, stack, and current
directory? ARexx should be versatile enough to do somthing about it, I
would think. Has anyone figured a way around this problem? Does Wsh
correct this problem? (I'm using shell 2.07m.)
2. I think this is just a bug. I cannot get a 'signal on break_c' to
work. (or break_d or break_e or break_f) It won't work in my programs,
and the supplied sample program breaksig.rexx doesn't work. I tried
this from a plain newcli, shell, and the new 1.3 Shell. Anybody gotten
this to work?
3. I would like to be able to call scripts from an application (Uedit)
and not wait for a reply before calling another one. Is this possible?
I can start multiple scripts running from cli's, and one from Uedit, and
have them all send messages to Uedit while the script that Uedit called is
still operating, and Uedit will deal with them all correctly. But until
the script that Uedit called terminates, Uedit cannot call another. It
tells me to fetch reply before sending a message, or something like
that. Is there a way that a script can send a reply to the program that
called it, and free up that port?
Thanks for any help.
--
---
Eric Kennedy
ejkst@cisunx.UUCP
|
| Art -
Thanks for replying, this sounded so basic, I was fairly certain
I was missing something. It appears as if ARexx gets spawned and
the new processes' cd is SYS:; this is a guess.
I worked around it in 1.3 by creating a "spawner" CLI execute script
which writes its current directory to a temporary RAM: file, invokes
the ARexx program, which has added code to read the temp file to get
its current directory (can you say "kludge"?). I still don't
understand why a CLI Execute script knows where it is, but an Arexx
program doesn't. There is one advantage in that after setting the CLI
script file's "s" protection bit and doing a "PATH ADD S:", I no
longer have to type the "rx".
This works, but it bothers me that ARexx can't even get the invoking
directory location, which to me seems a pretty basic requirement.
|
| I don't own AREX, but I suspect that .1 has correctly identified the
problem.
Every process in the Amiga has its own connected directory. Every CLI
process has its own command path. However, when a CLI process is
started, it inherits the current directory, command path, and lots
of other environment from its parent.
My understanding is that AREX runs in a separate process. Thus,
and command execute by AREX runs in the context of AREX's process.
(Or when AREX spawns a new CLI process, the environment of the
CLI process in inherited from the AREX process.)
Is AREX started by running it in your Startup-Sequence? If so, it
probably has the environment as it existed when AREX was started.
Thus, try setting up your command path before running AREX. You
can also establish a default directory for AREX by CDing to that
directory before running AREX.
Unfortunately, I know of no way to cause AREX to use the current directory
of its caller.
Execute gets the environment right because it runs in the CLI's own
process (all CLI commands do). In fact, when an Execute script contains
no argument substitutions, Execute merely redirects the CLI's command
input file pointer to the execute script and exits. The CLI then
begins reading and executing commands from the script.
|