home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 744 < prev    next >
Encoding:
Text File  |  1992-08-19  |  2.1 KB  |  47 lines

  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!utcsri!torn!watserv2.uwaterloo.ca!watserv1!csg.uwaterloo.ca!giguere
  3. From: giguere@csg.uwaterloo.ca (Eric Giguere)
  4. Subject: Re: Capturing System Command Output (was: SH Backquote)
  5. Message-ID: <Bt90J6.B88@watserv1.uwaterloo.ca>
  6. Sender: news@watserv1.uwaterloo.ca
  7. Organization: Computer Systems Group, University of Waterloo
  8. References: <ANDERS.92Aug18223235@lise8.lise.unit.no> <1992Aug19.191542.16996@wrkgrp.COM>
  9. Date: Wed, 19 Aug 1992 20:49:53 GMT
  10. Lines: 35
  11.  
  12. Just to muddle the discussion some more, it should be noted that ARexx (for
  13. the Amiga) extends the language by allowing external commands to return
  14. a result string instead of a return code.  This behaviour works as follows:
  15.  
  16.     /* simple use of command results */
  17.  
  18.     option results     /* used to turn on this behaviour */
  19.  
  20.     address myeditor
  21.     'openfile'
  22.     filename = result
  23.  
  24. The "option results" statement turns on the use of the result variable for
  25. result strings -- otherwise ARexx defaults to normal REXX behaviour.  When
  26. an external command is issued, a flag is set in the message that is sent
  27. to indicate that a result string is requested _if possible_.  If a result
  28. string makes sense, the application will set the RC field to 0 and 
  29. return the string in the RESULT field.  If RC is non-zero then the result
  30. string is ignored.
  31.  
  32. Note that this is NOT the same as redirecting command output.  This is
  33. just getting result string back from ARexx-aware applications.  These
  34. applications can also use the variable pool interface to directly set
  35. variables in the application.
  36.  
  37. But on the whole, a general approach still needs to be considered, and
  38. I'm not sure it should involve stacks and queues, which aren't necessarily
  39. defined in the host environment and may not make sense in a multitasking
  40. environment.  And then you have to consider systems like Microsoft Windows
  41. which already have a messaging protocol in wide use -- shouldn't REXX
  42. use it as well?
  43.  
  44. -- 
  45.  Eric Giguere                                    giguere@csg.UWaterloo.CA
  46.           So is Windows NT short for "Windows, NOT?"  
  47.