From: anders@lise11.lise.unit.no (Anders Christensen)
Subject: Re: Capturing System Command Output (was: SH Backquote)
Organization: /home/flipper/anders/.organization
Date: 20 Aug 92 02:19:39

In article <REXXLIST%92081920041037@DEARN> Otto Stolz <RZOTTO@DKNKURZ1.BITNET> writes:

>                                   I'll not quote those parts I agree
> with and have nothing to add to.

Sounds like a good custom. I'll try to do the same (hint hint)

> Apparently, Anders' examples assume that ls rather returns the filenames
> one per word;

Oops, sloppy programming by me. My only excuse is that I was trying
to show a point rather than constructing a program (did that sound
convincing? :-)

> > 1) CALLED AS A FUNCTION
> >       files = 'ls'(directory)

I'm becoming increasingly convinced that this might not be a very good
idea, and that this syntax should be reserved for external Rexx
functions (and programs pretending to be such.) You listed a few of
the potential problems, and there are several more, too. 

> > 2) EXTRA TERM IN COMMANDS [to] redirect the output [to] the stack:

I have since read Ed Spire's article on the ANSI REXX committee's
thoughts about the problem. I fell instantly in love with that syntax.
As you points out, similar syntax has already been implemented in several
environments:

> This is actually implemented
> - in OS/2 as "| rxstack",
> - in Personal REXX as ">STK:",
> - in CMS as "( LIFO", "( FIFO", or "( STACK" -- though only for
>   particular commands,
> - and in CMS Rel 7 (and older CMS Releases with CMS-Pipes added) as
>   "PIPE cms" ... "| stack", as in
	  "PIPE cms ls" directory "| stack".

but none of these seem as "Rexx'ish" the one suggested by Ed Spire. It
was more or less what I was looking for :-)

But, it does not address the problem of what to do with the standard
error (or other standard I/O streams.)

> > 3) READING COMMANDS WITH LINEIN.  A command is started with a builtin

> How will the interaction between the REXX program and its environment
> (or environments) be handled, in this scheme? 

What about the following:

   rcode = popen( 'prog',, "prog-input", "prog-output" )
   firstline = linein( 'prog-output' )
   if (firstline == 'something') then
      call lineout 'prog-input', 'input to prog'
   /* etc */

Then popen() would create both a input output (transient) stream
(which of course could be the same stream, too.) Depending on the
contents of the output of 'prog' you can feed it with the appropriate
input. 

Disadvantage: Yes, I know, the syntax above is terrible, and it isn't
at all easy to read. On the other hand. It extends the concept of a
stream to the communication with a running process. This is hardly a
very big step, since streams don't have to be persistent (file-type of)
streams. Actually, I believe some implementation have already done
that. 

> The basic idea is an explicit binding of the command output (from any
> environment) to a linein-stream; the particular syntax is negotiable :-)

Yes, I like the concept, and if the syntax could be negotiated into
something compatible with the proposed ADDRESS clause mentioned above,
I like the syntax too :-)

On the CMS issues, I stand corrected. It is far too long since I used
CMS, and I really shouldn't pretend that I remember anything :-(

> Remaining discrepancies:
> Even if one or several of the methods outlined above would become
> standard, REXX programs could not be more portable than their environ-
> ments would allow them to be! (viz. virtually not portable :-( )

Even if Rexx scripts aren't portable, Rexx users could take their
knowledge of Rexx to another platform. Having a common macro
processing language on multiple machine platforms and applications,
sounds like a big winner to me. That is the most important use for a
common syntax. The other important use is to get a common syntax for
all implementation on one platform (ref: at least four Unix
interpreters using different syntax.)

> The only way for the REXX programmer to strive for portability is to
> invent his or her own, system independend, set of primitives, implement
> them seperately for every system the programs are intended for, and use
> them in the rest of the programs in a system independend way.

But, suppose that set of primitives was a part of Rexx ... ?

-anders
Newsgroups: comp.lang.rexx