daveh@cbmvax.UUCP (Dave Haynie) (06/29/88)
in article <2119@cadovax.UUCP>, kaz@cadovax.UUCP (Kerry Zimmerman) says: > Keywords: ARexx > After reading so many glowing words about ARexx here on the net... > Why would I want to write a script in ARexx instead of using a CLI script > or a Shell script (using Matt's Shell)? I don't recall the examples on the ARexx disk offhand. But there are lots of things you can't do easily, or possibly at all, using the CLI script language, or probably Matt's shell language (tough I haven't used it myself). One of the features I like the most about the ARexx language is that it supports recursive subroutines, like any REAL computer language. Consider, for a moment, this problem. I've got gobs of stuff on my hard disk, all kinds of directories filled with Usenet downloads. I like to transfer whole directories over to floppy disks. I waste lots of time if I try to transfer a directory and find out that it won't fit on the space remaining on a floppy. So I want a function that'll tell me the size, in blocks, of a directory tree. Here's an ARexx solution, written in about 10 minutes. -----Cut Here----- /* Sizeblk.rexx Shows recursive function. -Dave Haynie */ parse arg dir . blocks = countblock(dir) say 'Total of' blocks 'blocks in directory' '9b'x'3m'dir'9b'x'0m' exit countblock : procedure arg dir blocks = 0 files = showdir(dir,'file') dirs = showdir(dir,'dir') call pragma 'Directory',dir do while files ~= '' parse var files oner . files = delword(files,1,1) blocks = blocks + subword(statef(oner),3,1) + 1 end do while dirs ~= '' parse var dirs oner . dirs = delword(dirs,1,1) blocks = blocks + countblock(oner) + 1 end call pragma 'Directory','/' return blocks -----Cut Here----- > No advantage is gained using ARexx over the CLI or Shell to communicate > with DOS that I know of. I'd be interested in seeing this done with CLI Scripts. You could certainly write a C program to do this, but it would be longer, and it would probably take more than 10 minutes to write. I guess it would be faster, too, but this is just an example. > Kerry Zimmerman > # {ucbvax,decvax}!trwrb!cadovax!kaz Contel Business Systems 213-323-8170 > A difference between an amateur and a professional, > is that a professional has the right tools. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
peter@sugar.UUCP (Peter da Silva) (06/29/88)
In article <4131@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > /* Sizeblk.rexx Shows recursive function. -Dave Haynie */ One problem: if you have any files with spaces in them, you'll be hosed. Because of the way REXX handles directories, it can't tell "foo bar" from two files named "foo" and "bar". I just spoke to Bill Hawes last night, and I forgot to bring this one up. Rats. -- -- `-_-' Peter (have you hugged your wolf today?) da Silva. -- U Mail to ...!uunet!sugar!peter, flames to /dev/null. -- "A foolish consistancy is the hobgoblin of little minds".
vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) (06/30/88)
In article <4131@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) points
out the main advantage of ARexx. Another point is that unlike other
inter-process-communication specs, you can get your hands on the public
data via the 'Clip List'. If the applications interface to ARexx 'correctly'
one would be able to integrate any set of applications. Unfortunately, the
milliunum isn't here yet. No application (capable of truly interactive
use, AmigaTeX doesn't count) I know of will communicate asynchronously with
ARexx. This is difficult but not impossible. At the least, I would like an
editor and a terminal emulator which do this. Any body know of such beasts.
(I have an order for TxEd Plus, but my dealer says that he has outstanding
backorders from last Nov. !?) rap@ardent.UUCP (06/30/88)
In article <4131@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <2119@cadovax.UUCP>, kaz@cadovax.UUCP (Kerry Zimmerman) says: > > Keywords: ARexx > > > After reading so many glowing words about ARexx here on the net... > > > Why would I want to write a script in ARexx instead of using a CLI script > > or a Shell script (using Matt's Shell)? > The other thing to consider is that when using ARexx, you can ask ARexx to perform one of its scripts (as I recall) from WITHIN another program and allow the script to communicate that result back to the program. This lets users of programs such as TxEd, with an ARexx port, to customize the menus to run various ARexx scripts on command (as was demonstrated at the most recent BADGE meeting). Using a shell script or a CLI script is more of a one-way street, probably requiring the use of the AmigaDOS Execute() function, perhaps returning a value (or a string) into a file, then your program mayhaps waits until the file exists (because Execute is asynchronous) to read the result. Using ARexx, you can make your "scriptural" calls either synchronous or async (depending on whether or not you wait at your ARexx reply port for the result to come back and the result is in the return value in your message packet that was sent to ARexx. Come to think of it, I don't remember a way (or is there) to send a script to the SHELL for execution (either 2.07m or the new 1.3 shell) other than via typical Execute("NewCLI from script",0,0). Perhaps someone could enlighten me on this part. (is it Execute("csh script",0,0)???) Rob Peck
acphssrw@csuna.UUCP (07/01/88)
Rob Peck wonders how to make the Dillon Shell do a script from an
Execute() call. The answer is that the Shell has both the "source"
command and the "-c" command line switch, so that:
Execute("shell -c source script-file",0,0);
will work fine.
This brings up something else: if you're going to do a lot of this
kind of thing (doing CLI stuff from ARexx scripts), you probably want
to buy ConMan and/or WShell. ConMan manages the input stream so that
one can use the ARexx PUSH and QUEUE commands to put CLI commands on
your CLI window's input stream. WShell gives you the ability to
overcome many of the limitations of Execute(), such as searching the
path. I normally keep non-CBM commands in a directory other than C:,
where ARexx's ADDRESS COMMAND (which does Execute()'s in the absence
of WShell) won't find them unless I hard-wire an explicit path into my
scripts.
Stephen Walton, representing myself swalton@solar.stanford.edu
Cal State, Northridge rckg01m@calstate.BITNETpapa@pollux.usc.edu.UUCP (07/01/88)
In article <18757@cornell.UUCP> blandy@cs.cornell.edu (Jim Blandy) writes: |I thought one of the main purposes of ARexx was to provide a command |language that ANY application could use. For example: right now, |DME, UEdit, and everybody else in the free world has their own little |scripting language; if they all had ARexx ports, you could program |them all in ARexx; ARexx would take care of parsing, and make the |interpreter code shared among clients. | |??? Is that right ??? Yes. That is easy for a package that already has a built-in script language, like A-Talk III (not released yet). Having an ATK ARexx port allows me to use the full power of ARexx to evaluate each and every parameter of A-Talk's script language commands. They can be evaluated as functions or entered interactively through ARexx consoles. Basically each parameter in A-Talk's script language is now a variable that can be evaluated with an ARexx script. The simplest thing looks like this: .... no = some number evaluated or interactively entered ADDRESS ATK DIAL no .... I have basically added the entire power of ARExx's expression evaluation to each and every parameters of A-Talk's Script language. If the package does NOT provide a buil-in script language, one has to be created. Microfiche Filer did just that. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
page@ulowell.UUCP (07/01/88)
[comp.sys.amiga.* gets a lot of messages in two weeks! :-) ] Bill Hawes said he was surprised at the number of people using ARexx as a programming language; he had only intended it to be complete and small, so programs could use it for IPC and macros. Turns out since so many people use it as a programming langauge (it's great for prototyping), he's working on improving its performance. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
vkr@osupyr.mast.ohio-state.edu.UUCP (07/02/88)
'r' command. It kick me out :-(] The answer is yes. But I do need one thing: UEdit must tell its state to all comers [with the proviso that this is always subject to change.] Does it have such a function? BTW, is this the commercial version and how do you feel about it. In particular how does it compare to TxEdPlus?
ejkst@cisunx.UUCP (Eric J. Kennedy) (07/08/88)
In article <650@osupyr.mast.ohio-state.edu> vkr@osupyr.mast.ohio-state.edu (Vidhyanath K. Rao) writes: >The answer is yes. But I do need one thing: UEdit must tell its state >to all comers [with the proviso that this is always subject to change.] >Does it have such a function? BTW, is this the commercial version and >how do you feel about it. In particular how does it compare to TxEdPlus? Again, I do not have Arexx yet. But, reading the docs, it seems that Uedit has an "Auto-traffic" command, which "Toggles auto-traffic mode. If auto-traffic mode is ON, the idle comand handles all ARexx traffic." This may be what you're asking for. Also, it says "Also, in CLI or a shell, you can control Uedit using ARexx messags." The previous quotes and and the following are taken from the may 16 Uedit Customer Mailing. ---- The following apply to Auto-traffic mode. When auto-traffic mode is Off, traffic is handled at your discretion, using the commands above. [Err, see the menu command below. -ejk] When auto-traffic mode is turned On, traffic is processed by the idle command. The following types of messages ar processed. (This is, of course, customizable): 1. If the messags has an "f:" prefix, Uedit loads the file whose filename is given. Example: rx f:myDir/myFile If Uedit is in Tiny Window when a message arrives, it springs back to its big window and processes the message. This gives you a faster in-and-out editing capability like smaller editors are noted for. 2. If the message has a "c:" prefix, it is interpreted as a series of inputs. Messags can send a series of inputs to Uedit (commands and text), controlling it from outside. The "Make x.rexx" command lets you build such a message automatically by pressing the desired keys, just as in Learn Mode. Once it is saved to disk, you can use it in CLI by typing: rx x 3. If the message has no prefix, its text is inserted at the cursor location. Example: rx u This is my text to go into Uedit at the cursor. Command language interface: The interface is powerful and flexible. Two functions, rexxIn() and rexxOut(), are used. Default action codes correspond to common ARexx message types. You can override the defaults by using reall ARexx action codes and flag bit modifiers. The "Uedit <====> Rexx" menu commands supplied are: "ED out buffer" Edit ARexx output buffer "ED in buffer " Edit ARexx input buffer "Out->Rexx " Send output buffer to ARexx. "In<-Rexx " Fetch ARexx input into input buffer. "Hilite->Rexx " Send hilite region to ARexx. "Cursor<-Rexx " Fetch ARexx input at cursor in current buffer. "Reply OKAY-> " Send OKAY reply to last message. "Reply text-> " Send OKAY reply plus hilited ext to last msg (if incoming message asked for a text result). "Auto-traffic " Toggle auto-traffic mode. If auto-traffic mode is ON, the idle command handles all ARexxs traffic. "Make x.rexx " Create an ARexx program to send inputs to Uedit. ------------------------- Hope this answers some of your questions. BTW, naturally, you can write your own commands for using the ARexx ports. For instance, I'm about to order ARexx and AmigaTeX, and I plan to write "TeX buffer" and "TeX hilite" commands. Oh, yes, I believe the redistributable version of Uedit 2.3h (UES) also has the ARexx port. I don't use UES, since I have a compulsive need to program Uedit. In other words, I use the commercial version, but as far as I know, the shareware or distributable version has the ARexx port, too. (I'll check on that, though.) Regarding TxED Plus, I've never seen it. -- ------------ Eric Kennedy ejkst@cisunx.UUCP
ejkst@cisunx.UUCP (Eric J. Kennedy) (11/16/88)
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
lphillips@lpami.van-bc.UUCP (Larry Phillips) (11/22/88)
> 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.... It's a problem with Amigados and current directory (according to Bill Hawes). I work around it for now by using either ASIGNed names or the 'pragma' function. With pragma, you can set up a 'home position' and go from there. WShell suffers from the same problem. I do believe it's the same things as happens with PopCLI III. > 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? Yes. I have a small BBS program written completely in ARexx that uses the AUX: handler and a NewWsh. Of course since the caller is actually using a CLI from the serial port, it would never do to allow him to ^C out of it. I don't know if the WShell makes any difference, but the 'break' code works fine... signal on break_c signal on break_d signal on break_e signal on break_f signal on halt signal on ioerr .... here be Arexx code ... break_c: break_d: break_e: break_f: halt: ioerr: return 0 ---- end of program --- > 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? I don't know about UEdit in particular, but yes, multiple script calls from a program is possible, as are multiple calls to functions within one script. When you call a script from a program, the reply must come from the resident process ('REXX') itself, and that reply probably comes after the script called has exited. I am working on a small serial module that can communicate with one or more ARexx scripts and one or more other modules (and vice versa, communication is fully bidirectional). Calls sent via messages from the program to an opened port within the script are answered explicitly within the script, soon or not-so-soon, depending on the function being performed. Since the RexxMessages are allocated at the time of sending, there can be multiple outstanding messages in either direction. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------+ | // Larry Phillips | | \X/ lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
ejkst@cisunx.UUCP (Eric J. Kennedy) (11/24/88)
In article <1969@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: >> 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? >When you call a script from a program, the reply must come from the >resident process ('REXX') itself, and that reply probably comes after the >script called has exited. But I want that reply to come during the execution of the script, not after it exits. Here's what I'm trying to do. Uedit saves my TeX file, and calls the script 'texify.urexx'. This script tells AmigaTeX to process the file, then sends a message to Uedit that the operation succeded. ("TeXifying..." appears in the message bar.) Since it's asynchronous, Uedit allows me to continue editing as soon as the script is started. Now, if TeX successfully finishes, the script sends another message to Uedit. ("AmigaTeX successful") But if there's an error, the script sends the file name, row and column of error, and Uedit dutifully jumps to the location of the error. The problem is, I can have the script telling Uedit to do all of these things, and Uedit does them and sends a reply, but Uedit can't send a message back to the script. I would like to be able to deal with the error message from Uedit, but since it's waiting for a message and can't send another one, I have to flip back to the TeX window and deal with the error there. I can do all of this if I would execute the script from the cli using 'rx'. Uedit and the script can then have unchecked two-way communication. But it won't work if Uedit calls the script. So, is there a way to send a reply to the program that called the script, so the two can have two-way communication? Thanks, -- --- Eric Kennedy ejkst@cisunx.UUCP
lphillips@lpami.van-bc.UUCP (Larry Phillips) (11/25/88)
> The problem is, I can have the script telling Uedit to do all of these > things, and Uedit does them and sends a reply, but Uedit can't send a > message back to the script. I would like to be able to deal with the > error message from Uedit, but since it's waiting for a message and > can't send another one, I have to flip back to the TeX window and deal > with the error there. > I can do all of this if I would execute the script from the cli using > 'rx'. Uedit and the script can then have unchecked two-way > communication. But it won't work if Uedit calls the script. So, is > there a way to send a reply to the program that called the script, so > the two can have two-way communication? Well, I'm not sure I can visualize this problem poperly without actually using UEdit and TeX, but your last paragraph may hold the answer. You can effectively start a script from a CLI using 'rx' by calling a script from UEdit that in turn calls the 'texify' script. The script that kicks everything off can be quite short, returning immediately, giving 'control' back to UEdit. Remember that scripts can also communicate with each other, so if that is useful to you, you can do more than just start texify.rexx In addition to starting the whole process, you can also use other scripts at any point during the process to do various things for you. These can be started by texify.rexx, and (I presume) by UEdit and TeX. I ran into what may be a similar problem using TxEd and ARexx, where a script seemed to hang when it was put into a Wait, waiting for a message from TxEd, and I solved the problem by kicking off another script from TxEd to actually send the necessary message. Hope this leads to some success. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------+ | // Larry Phillips | | \X/ lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+