Newsgroups: comp.lang.rexx
Date:         Wed, 19 Aug 1992 14:56:12 CST
From:         Jim Colten <IJIM@UMINN1.BITNET>
Subject:      Re: Capturing System Command Output (was: SH Backquote)

On Wed, 19 Aug 1992 19:15:42 GMT Edward T Spire said:
>   ... much deleted

>
>Standardization of the redirection of the external command's stdin and
>stdout.
>

by all means, do standardize this!

>  ... more deleted
>
>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.

there would surely be some interference between uses of stdin/stdout but
'point use' of such a feature (Address environment host-command from ... to ...
would seem to allow the programmer to limit (control?) that interference.

Even being from a CMS environment where the stack has long been a way of life,
I CANNOT voice support for institutionalizing yet another use of the stack.

The stack has been great, especially in light of the bizarre techniques we
used before widespread stack support became available (the stuff that legends
were made of), but the stack is not a feature for the nineties.  Please allow
it to grow old gracefully into a beloved but seldom needed anachronism.

>
>The user representatives were adamant that possible specifications for
>"source" and "destination" should also include:
>
>  VAR symbol
>  STEM symbol.

*JUSTIFIABLY ADAMANT*! although I do acknowledge VAR's line separation
diffuculties mentioned below.

>
>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.

Huh?  There are already widely followed conventions for this TYPE of use of
stem variables.  Granted, these uses are not (yet) part of the language
definition, but the concepts are well developed and well accepted. This kind of
proven user experience is the *BEST* source of ideas for new function. Please
explain the need for caution in this particular case. If caution is warranted
in this discussion, it is for the basic premise, re-direction of host command
I/O, but we have already crossed that bridge and caution did not get in the
way.


>                                  These last two options will certainly
>be considered for inclusion in the second standard.
>

Please re-consider the delay.

Jim Colten
University of Minnesota
Newsgroups: comp.lang.rexx