home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 745 < prev    next >
Encoding:
Text File  |  1992-08-19  |  3.7 KB  |  97 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!darwin.sura.net!paladin.american.edu!auvm!UMINN1.BITNET!IJIM
  3. Message-ID: <REXXLIST%92081916421560@UGA.CC.UGA.EDU>
  4. Newsgroups: comp.lang.rexx
  5. Date:         Wed, 19 Aug 1992 14:56:12 CST
  6. Sender:       REXX Programming discussion list <REXXLIST@UGA.BITNET>
  7. From:         Jim Colten <IJIM@UMINN1.BITNET>
  8. Subject:      Re: Capturing System Command Output (was: SH Backquote)
  9. In-Reply-To:  Message of Wed, 19 Aug 1992 19:15:42 GMT from <ets@WRKGRP.COM>
  10. Lines: 85
  11.  
  12. On Wed, 19 Aug 1992 19:15:42 GMT Edward T Spire said:
  13. >   ... much deleted
  14.  
  15. >
  16. >Standardization of the redirection of the external command's stdin and
  17. >stdout.
  18. >
  19.  
  20. by all means, do standardize this!
  21.  
  22. >  ... more deleted
  23. >
  24. >The user organizations among the committee members felt very strongly
  25. >that the standard should address this issue.  The committee settled on
  26. >a tentative syntax extension to the ADDRESS instruction that would
  27. >implement a redirection of the external command's stdin and/or stdout
  28. >I/O stream.  One possible syntax would be:
  29. >
  30. >    ADDRESS environment [FROM source] [TO destination] [exprc]
  31. >      or
  32. >    ADDRESS [VALUE] exprv [FROM source] [TO destination]
  33. >
  34. >The committee agreed that "source" could be one of:
  35. >
  36. >   STDOUT (i.e., the REXX language processor's stdout stream)
  37. >   QUEUE
  38. >
  39. >and "destination" could be one of:
  40. >
  41. >   STDIN
  42. >   QUEUE (FIFO to the stack)
  43. >   PUSH  (LIFO to the stack.)
  44. >
  45. >It was recognized that the connection of the external commands stdin/out
  46. >to the REXX program's stdin/out may be the less useful of the pair,
  47. >since it would interfere with the REXX program's normal use of stdin/out.
  48.  
  49. there would surely be some interference between uses of stdin/stdout but
  50. 'point use' of such a feature (Address environment host-command from ... to ...
  51. would seem to allow the programmer to limit (control?) that interference.
  52.  
  53. Even being from a CMS environment where the stack has long been a way of life,
  54. I CANNOT voice support for institutionalizing yet another use of the stack.
  55.  
  56. The stack has been great, especially in light of the bizarre techniques we
  57. used before widespread stack support became available (the stuff that legends
  58. were made of), but the stack is not a feature for the nineties.  Please allow
  59. it to grow old gracefully into a beloved but seldom needed anachronism.
  60.  
  61. >
  62. >The user representatives were adamant that possible specifications for
  63. >"source" and "destination" should also include:
  64. >
  65. >  VAR symbol
  66. >  STEM symbol.
  67.  
  68. *JUSTIFIABLY ADAMANT*! although I do acknowledge VAR's line separation
  69. diffuculties mentioned below.
  70.  
  71. >
  72. >to allow redirection to REXX variables.  The committee could not agree
  73. >that these latter extensions were warranted for the initial standard.
  74. >The former has line separation difficulties (what can be chosen as a
  75. >uniformly applicable line delimiter?), while the latter introduces a
  76. >new means of utilizing stem variables into the language, which should
  77. >be approached with some caution.
  78.  
  79. Huh?  There are already widely followed conventions for this TYPE of use of
  80. stem variables.  Granted, these uses are not (yet) part of the language
  81. definition, but the concepts are well developed and well accepted. This kind of
  82. proven user experience is the *BEST* source of ideas for new function. Please
  83. explain the need for caution in this particular case. If caution is warranted
  84. in this discussion, it is for the basic premise, re-direction of host command
  85. I/O, but we have already crossed that bridge and caution did not get in the
  86. way.
  87.  
  88.  
  89. >                                  These last two options will certainly
  90. >be considered for inclusion in the second standard.
  91. >
  92.  
  93. Please re-consider the delay.
  94.  
  95. Jim Colten
  96. University of Minnesota
  97.