From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: Capturing System Command Output (was: SH Backquote)
Organization: The Workstation Group
Date: Fri, 28 Aug 92 18:33:36 GMT

anders@lise3.lise.unit.no (Anders Christensen) writes:
: In article <1992Aug24.150430.3770@wrkgrp.COM> ets@wrkgrp.COM (Edward T Spire) writes:
: 
: > : [ on the syntax   ADDRESS ... TO/FROM STREAM streamid ...]
: 
: > Note that the connections to REXX I/O streams simply replace the
: > external data queue as a place to queue up input lines to be processed
: > by the command and output from the command.  The command still runs
: > synchronously, with no real interaction between the REXX program and
: > the command. 
: 
: Why? The only thing needed in order to make this async, is to make the
: environment aware that is should start the command in the background.
: The "environment" in rexx is some slightly undefined entity which is
: half inside the interpreter and half outside. At least under Un*x,
: this could be done something like this:
: 
:    ADDRESS unix "cmd &" TO STREAM outdata FROM STREAM indata
: 
: Then, 'cmd' runs in the background, and 'outdata' and 'indata'
: provides means to communicate with it. The interpreter controls the
: execution of 'cmd' by either reading 'outdata' and writing 'indata'. 
: 
: Other operating system has different syntax to make commands run in
: the background. Exactly how this is done is not really within the
: domain of Rexx. But perhaps an extra subkeyword "ASYNC" should be
: added, so that the interpreter itself knows explicitly that the
: command should run in the background if possible. I am not so sure
: about that.
:
: >              If you want the command to run asynchronously, so that the
: > REXX program can see some of the command's output before deciding upon
: > the rest of it's input, you'll probably want a function call-based
: > approach.
: 
: Some environments are not really suited for async execution, i.e. they
: cannot start a new command before the previous command is ended. In
: these environments, the interpreter will have to be restricted to not
: run another command before the previous was finished. 
: 
: I think the ADDRESS syntax is general enough to handle async commands
: too. I don't want to use functions to start commands. The command
: concept in Rexx is very elegant, and I want to use commands to perform
: commands. I have nothing against using functions to _communicate_ with
: the command running, but I'd like to start it as a command. 

Well, right off the top of my head, I see no reason why this could not
be made to work.  However, it is a pretty long way from where we are now
and it would have to be approached with some caution.
  
You would need to firm up this idea of using a program-specified
filename as a handle on an interprocess communications port, and think
about it's impact on the file namespace and accessibility to other
files, etc.
  
You would need a set of functions to control the async process, tell
what it's state is, is it waiting for input, kill it, notice it's
termination, determine it's final return code, etc.
  
The nice thing about doing this kind of stuff exclusively with functions
is that it's easy to test (external functions) and you don't risk the
chance of damaging the language when you do it that way.

My impression is that it was no small feat to craft REXX so that it is
easy to use and powerful at the same time.  I would not want to go
wading off on some large extensions like this without their being
carefully thought out and field tested.
  
-Ed