home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 766 < prev    next >
Encoding:
Text File  |  1992-08-22  |  4.4 KB  |  114 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!paladin.american.edu!auvm!SERVER.UWINDSOR.CA!OPHOF
  3. X-Mailer: ELM [version 2.3 PL11]
  4. Message-ID: <9208220504.AA15489@SERVER.uwindsor.ca>
  5. Newsgroups: comp.lang.rexx
  6. Date:         Sat, 22 Aug 1992 01:03:28 EDT
  7. Sender:       REXX Programming discussion list <REXXLIST@UGA.BITNET>
  8. From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
  9. Subject:      Re: Capturing System Command Output
  10. Comments: To: REXXLIST@uga.cc.uga.edu
  11. In-Reply-To:  <9208200611.AA14281@SERVER.uwindsor.ca>; from "Anders
  12.               Christensen" at Aug 20, 92 6:50 am
  13. Lines: 99
  14.  
  15. On Thu, 20 Aug 1992 06:50:53 LCL Anders Christensen said:
  16. ...
  17. >What about the the following syntax, which is a slightly reworked
  18. >version of what Ed Spire just posted. It also borrows inspiration from
  19. >some of the ideas that Otto Stolz posted. This is a all-in-one
  20. >solution, combining the current 'standard' way to do it with the need
  21. >for more control over the redirection of input and output.
  22.  
  23. >| ADDRESS [ envir [ exprc [ TO dest ] [ FROM src ] ] ]
  24.  
  25. As defined here, "dest" and "src" *must* be specified if the
  26. corresponding keyword is specified.  At least if I read this
  27. according to the standard CMS rules for syntax description.  ;-)
  28. Thus there can NOT be a default if either the "TO" and/or "FROM"
  29. keywords are specified.  So "OUTPUT" is only a default for "dest"
  30. if "TO" is *not* specified (same for "INPUT" etc.).
  31.  
  32. Another point:
  33. Is there any reason to allow specification of "TO dest" and/or "FROM
  34. src" *only* if "exprc" is specified?  In other words:
  35.    ADDRESS envir
  36. is allowed, so why not:
  37.    ADDRESS envir TO dest FROM src
  38.  
  39. So as full syntax:
  40.    ADDRESS [ envir [ exprc ]    [ TO dest ] [ FROM src ] ]
  41. or even:
  42.    ADDRESS [ envir [ exprc ] ]  [ TO dest ] [ FROM src ]
  43.  
  44.  
  45. >|     <exprc> is the command to be executed. One restriction applies,
  46. >|             "TO" and "FROM" are reserved words, and can not be
  47. >|             used in unquoted form.
  48.  
  49. This restriction seems unnecessary if my above point re stricter
  50. syntax is valid.  (?)
  51.  
  52.  
  53. >|     <dest>  =  OUTPUT         output to standard output (default)
  54.  
  55. "Corrected" definition: "(default if "TO" is NOT specified)"
  56. (according to that stricter syntax definition)
  57.  
  58.  
  59. >...             I can't think of any example of redirection of
  60. >commands the during resent days that would not be handled with this
  61. >expanded ADDRESS clause.
  62.  
  63. Has the ANSIREXX committee come up with any opsyses where this form
  64. might NOT be general enough to cover all possibilities?
  65.  
  66.  
  67. >Then there is the 'breakage' to consider. Old commands using 'to' and
  68. >'from' in commands. I can imagine a lot of old Rexx scripts having
  69. >constructs like:
  70. >    COPY from to
  71.  
  72. Assuming you mean:
  73.    ADDRESS envir "COPY" from to
  74. (which isn't as obvious as it seems if your comment re use of TO and
  75. FROM as subkeywords in ordinary commands is included...  ;-) )
  76. then an arg like "REDIRECTION" might be needed in the OPTIONS
  77. instruction...  Not that I like that idea...
  78.  
  79. Maybe an extra keyword?
  80.    ADDRESS [ envir [ exprc ] ]  [ REDIRECT { TO    dest } ]
  81.                                 [          { FROM  src  } ]
  82. This also makes clear beyond any doubt what's meant with the "TO"
  83. and "FROM" parts...
  84. Does anyone have a good suggestion where such a hopefully unneeded
  85. extra keyword can be dropped by alternative ordering?
  86.  
  87.  
  88. >Then there are the ordinary commands, which are more or less just
  89. >special cases of ADDRESS (not defined as so in TRL, but at least used
  90. >as such; omit the "ADDRESS <envir>", and you've got a command). If
  91. >the same changes are applies to commands (acknowledging "TO" and
  92. >"FROM" as subkeywords), Rexx would have full support for redirection
  93. >of output and input to commands.
  94.  
  95. Using TO and FROM in the ADDRESS instruction, I can understand that.
  96. But I would *not* like to see such keywords applicable to a command
  97. not prefaced with ADDRESS...
  98.  
  99.  
  100. >However, it still does not handle the problem of error output. Any
  101. >error text that a command might write out should be possible to catch
  102. >in some way. Maybe it could be fixed by adding a 'ERROR' subkeyword
  103. >in addition to "TO" and "FROM"?
  104.  
  105. "INPUT", "OUTPUT", and "ERROR" are all streams, aren't they?
  106. Is there any problem with seeing the stack as a stream?
  107. And including the comment re VMS having even more streams than UN*X,
  108. an approach from the angle of streams in general might be better?
  109. ADDRESS seems close to becoming rather unwieldy...
  110.  
  111.  
  112. Regards.
  113. $$/
  114.