home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.rexx
- Path: sparky!uunet!wrkgrp!ets
- From: ets@wrkgrp.COM (Edward T Spire)
- Subject: Re: Capturing System Command Output (was: SH Backquote)
- Message-ID: <1992Aug19.191542.16996@wrkgrp.COM>
- Organization: The Workstation Group
- References: <ANDERS.92Aug18223235@lise8.lise.unit.no>
- Date: Wed, 19 Aug 92 19:15:42 GMT
- Lines: 117
-
- anders@lise8.lise.unit.no (Anders Christensen) writes:
- : In article <19920818081215SEB1525@MVS.draper.com> SEB1525@MVS.draper.com (Steve Bacher) writes:
- :
- : > Is anyone working on defining a standard syntax for this capability?
- :
- : If there anyone from the ANSI committee present, that would tell what
- : they intend to do with this problem?
-
- This area was discussed at the last session, and will be discussed again
- next month. Here's what was published at the end of the last session
- on this issue.
-
-
-
- (The following is an excerpt from ANSI document number X3J18/92-009,
- "X3J18 REXX Standards Committee fourth meeting's discussion notes")
-
-
-
- Commands to an External Environment
-
- Two issues were discussed concerning commands to the external environment:
- Portability of completion analysis, and standardization of the
- redirection of the external command's stdin and stdout.
-
-
- Portability of completion analysis.
-
- Even though most implementations utilize a numeric RC with fairly
- common standards (i.e., 0=normal completion) it was recognized that
- the language definition cannot standardize the RC returned from the
- external environment, therefore portability in analyzing the result
- of external commands is a problem.
-
- In fact, it was noted that some implementations allow the completion
- status of the external command to be indicated independently from the
- return code.
-
- The committee is leaning towards providing yet another special variable
- to indicate the completion status of the command to the external
- environment in a standard manner. We have some concern regarding
- adding yet another special variable, so our first choice was to
- use "result", which is already a special variable, which is not set
- by an external command (according to TRL). However, the AmigaDos
- implementation of REXX (AREXX) does set "result" in response to some
- external commands, and there was also concern that some programs
- already using result would expect it to be preserved across an
- external command. Hence the committee is leaning towards adding the
- special variable "rs", which would be assigned the value -1, 0, or 1
- upon the completion of an external command, meaning failure, normal,
- or error status.
-
- We should note once again that the issue of removing all special variables
- and replacing them with functions was once again raised as a way to
- simplify the language, rather than further complicate it by adding
- still more special variables. An alternate suggestion of using a reserved
- name space for special variables (i.e., _rc, _result, _rs, etc.) was
- also discussed.
-
-
- Standardization of the redirection of the external command's stdin and
- stdout.
-
- While many operating systems provide a means to redirect the standard
- input and output streams for external commands to various sources,
- there is little consistency among environments. Often REXX language
- extensions are required for various environments (such as the creation
- of an external data queue for those environments that do not implement
- one, including a mechanism to redirect command output there.) Without
- guidance from the language definition, such language extensions tend to
- vary widely from platform to platform.
-
- The user organizations among the committee members felt very strongly
- that the standard should address this issue. The committee settled on
- a tentative syntax extension to the ADDRESS instruction that would
- implement a redirection of the external command's stdin and/or stdout
- I/O stream. One possible syntax would be:
-
- ADDRESS environment [FROM source] [TO destination] [exprc]
- or
- ADDRESS [VALUE] exprv [FROM source] [TO destination]
-
- The committee agreed that "source" could be one of:
-
- STDOUT (i.e., the REXX language processor's stdout stream)
- QUEUE
-
- and "destination" could be one of:
-
- STDIN
- QUEUE (FIFO to the stack)
- PUSH (LIFO to the stack.)
-
- It was recognized that the connection of the external commands stdin/out
- to the REXX program's stdin/out may be the less useful of the pair,
- since it would interfere with the REXX program's normal use of stdin/out.
-
- The user representatives were adamant that possible specifications for
- "source" and "destination" should also include:
-
- VAR symbol
- STEM symbol.
-
- to allow redirection to REXX variables. The committee could not agree
- that these latter extensions were warranted for the initial standard.
- The former has line separation difficulties (what can be chosen as a
- uniformly applicable line delimiter?), while the latter introduces a
- new means of utilizing stem variables into the language, which should
- be approached with some caution. These last two options will certainly
- be considered for inclusion in the second standard.
-
- ==========================================================================
-
- Ed Spire email: ets@wrkgrp.com (on uunet)
- The Workstation Group voice: 800-228-0255
- 6300 River Road, Suite 700 or 708-696-4800
- Rosemont, Illinois 60018 fax: 708-696-2277
-