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

  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!wrkgrp!ets
  3. From: ets@wrkgrp.COM (Edward T Spire)
  4. Subject: Re: Capturing System Command Output (was: SH Backquote)
  5. Message-ID: <1992Aug19.191542.16996@wrkgrp.COM>
  6. Organization: The Workstation Group
  7. References: <ANDERS.92Aug18223235@lise8.lise.unit.no>
  8. Date: Wed, 19 Aug 92 19:15:42 GMT
  9. Lines: 117
  10.  
  11. anders@lise8.lise.unit.no (Anders Christensen) writes:
  12. : In article <19920818081215SEB1525@MVS.draper.com> SEB1525@MVS.draper.com (Steve Bacher) writes:
  13. : > Is anyone working on defining a standard syntax for this capability?
  14. : If there anyone from the ANSI committee present, that would tell what
  15. : they intend to do with this problem?
  16.  
  17. This area was discussed at the last session, and will be discussed again
  18. next month.  Here's what was published at the end of the last session
  19. on this issue.
  20.  
  21.  
  22.  
  23. (The following is an excerpt from ANSI document number X3J18/92-009,
  24. "X3J18 REXX Standards Committee fourth meeting's discussion notes")
  25.  
  26.  
  27.  
  28. Commands to an External Environment
  29.  
  30. Two issues were discussed concerning commands to the external environment:
  31. Portability of completion analysis, and standardization of the
  32. redirection of the external command's stdin and stdout.
  33.  
  34.  
  35. Portability of completion analysis.
  36.  
  37. Even though most implementations utilize a numeric RC with fairly
  38. common standards (i.e., 0=normal completion) it was recognized that
  39. the language definition cannot standardize the RC returned from the
  40. external environment, therefore portability in analyzing the result
  41. of external commands is a problem.
  42.  
  43. In fact, it was noted that some implementations allow the completion
  44. status of the external command to be indicated independently from the
  45. return code.
  46.  
  47. The committee is leaning towards providing yet another special variable
  48. to indicate the completion status of the command to the external
  49. environment in a standard manner.  We have some concern regarding
  50. adding yet another special variable, so our first choice was to
  51. use "result", which is already a special variable, which is not set
  52. by an external command (according to TRL).  However, the AmigaDos
  53. implementation of REXX (AREXX) does set "result" in response to some
  54. external commands, and there was also concern that some programs
  55. already using result would expect it to be preserved across an
  56. external command.  Hence the committee is leaning towards adding the
  57. special variable "rs", which would be assigned the value -1, 0, or 1
  58. upon the completion of an external command, meaning failure, normal,
  59. or error status.
  60.  
  61. We should note once again that the issue of removing all special variables
  62. and replacing them with functions was once again raised as a way to
  63. simplify the language, rather than further complicate it by adding
  64. still more special variables.  An alternate suggestion of using a reserved
  65. name space for special variables (i.e., _rc, _result, _rs, etc.) was
  66. also discussed.
  67.  
  68.  
  69. Standardization of the redirection of the external command's stdin and
  70. stdout.
  71.  
  72. While many operating systems provide a means to redirect the standard
  73. input and output streams for external commands to various sources,
  74. there is little consistency among environments.  Often REXX language
  75. extensions are required for various environments (such as the creation
  76. of an external data queue for those environments that do not implement
  77. one, including a mechanism to redirect command output there.)  Without
  78. guidance from the language definition, such language extensions tend to
  79. vary widely from platform to platform.
  80.  
  81. The user organizations among the committee members felt very strongly
  82. that the standard should address this issue.  The committee settled on
  83. a tentative syntax extension to the ADDRESS instruction that would
  84. implement a redirection of the external command's stdin and/or stdout
  85. I/O stream.  One possible syntax would be:
  86.  
  87.     ADDRESS environment [FROM source] [TO destination] [exprc]
  88.       or
  89.     ADDRESS [VALUE] exprv [FROM source] [TO destination]
  90.  
  91. The committee agreed that "source" could be one of:
  92.  
  93.    STDOUT (i.e., the REXX language processor's stdout stream)
  94.    QUEUE 
  95.  
  96. and "destination" could be one of:
  97.  
  98.    STDIN
  99.    QUEUE (FIFO to the stack)
  100.    PUSH  (LIFO to the stack.)
  101.  
  102. It was recognized that the connection of the external commands stdin/out
  103. to the REXX program's stdin/out may be the less useful of the pair,
  104. since it would interfere with the REXX program's normal use of stdin/out.
  105.  
  106. The user representatives were adamant that possible specifications for
  107. "source" and "destination" should also include:
  108.  
  109.   VAR symbol
  110.   STEM symbol.
  111.  
  112. to allow redirection to REXX variables.  The committee could not agree
  113. that these latter extensions were warranted for the initial standard.
  114. The former has line separation difficulties (what can be chosen as a
  115. uniformly applicable line delimiter?), while the latter introduces a
  116. new means of utilizing stem variables into the language, which should
  117. be approached with some caution.  These last two options will certainly
  118. be considered for inclusion in the second standard.
  119.  
  120. ==========================================================================
  121.  
  122. Ed Spire                           email: ets@wrkgrp.com      (on uunet)
  123. The Workstation Group              voice: 800-228-0255
  124. 6300 River Road, Suite 700            or  708-696-4800
  125. Rosemont, Illinois  60018            fax: 708-696-2277
  126.