CompuServe Thread

LC from TxED

5 messages in this thread
#28787From: Gabe J. FederJan 4, 1989 1:16 PM
Bill, Any reason why doing a compile from within a .txed ARexx program fails? Here's what I do (in rough paraphrase): .save the file in a work directory (say RAM: or VD0:) under a specific workfile name using the TxED save "filename" command .address command .lc -L filename the lc command returns a -2 rc, and fails. The lc command actually uses a few more parms that I don't currently recall, but the EXACT same lc command succeeds in my shell level (CBM's 1.3 shell). The important feature here, as far as I can tell, is that the lc, lc1, lc2, and blink commands are resident. I have not yet tried this with those commands sitting happily in c: where they normally are. Also, these babys don't really live in c, either on my boot disk. I guess I'll give it a shot on the clean side. –Gabe (trying, but failing, to live a clean life)
#28877From: Bill HawesJan 4, 1989 10:17 PM
Gabe, Running commands using the "address command" facility in ARexx normally requires that you supply a full path for the command you're running, or that the commands be in C:. The reason for the limitations is that "address command" isn't really an ARexx host; it's just passing the command string to AmigaDOS, and the DOS facility has a lot of shortcomings. From your description of the problem it sounds like LC can't find the commands it needs from this environment. Bill
#28971From: Gabe J. FederJan 5, 1989 10:58 AM
That must be it, Bill. Somehow, Ados cannot find resident commands when you have sent it the strings. I guess you must use Execute() to send the command string? If so, might it be that it starts a CLI, and not a shell, so that could be causing part of the problem (?) I guess so, because… As to the commands, no, actually they are NOT in c:, but in a dir off of C: (commands that I use an SPAT RESIDENT df0:c/radc/#? to set up in my s-s). So,… you do an Execute(), there are no RESIDENTs in CLI, as there are in shell, looks to c:, and cannot find the commands. Hmmm, sounds reasonable. OK, so the solution(s) might include: 1) Workaround for now — the obvious: put the LC commands back in C: –or– 2) Include the path (less painful for me, but I'd still get rid of the RESIDENTs in this case, no need to have 'em there if I have to use C: anyway. –or– 3) Try to do a NEWSHELL NEWCON:0/0/300/100/test from compileit where compileit is in S: and does a RX compile. (Yick, this is messy!) –or– 4) Can I do an OPEN() of NEWCON: and submit a command to it? –or– 5) Might you be able to rewrite for a new release using a version of Execute() that uses an ADOS Shell? (If such exists?) –Gabe
#29013From: Bill HawesJan 1, 1970 12:00 AM
Gabe, Commodore hasn't documented anything regarding to how their shell can be invoked by Execute(), although I had thought that the 1.3 RUN command (which is used to process the command) was smart enough to look for shell-seg on the residnet list. There is a much better solution, however, which is to use WShell to run the commands. SInce it has a real ARexx interface, the commands get issued directly to WShell (i.e. you don't need to use "address command"), and the return code from the command is available to your macro program. WShell is quite compatible with the CLI and 1.3 shell, so you don't need to learn a lot of new commands, and it has some nice features like a configurable titlebar and prompt string, implicit CD command, and support for a close gadget on your window. Bill Hawes
#29058From: RENE LEBLANCJan 5, 1989 10:25 PM
Thanks for your message regarding #LC from TxED, but I'm confused. I wonder if you might be answering somebody else's mail. I don't use TxED; I use Uedit. I haven't had a problem of compiling from within a .txed ARexx program… I'm not even sure what that means. Sorry, but I might be the wrong recipient.