home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 750 < prev    next >
Encoding:
Text File  |  1992-08-19  |  4.6 KB  |  113 lines
  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!kithrup!hoptoad!decwrl!mips!darwin.sura.net!jvnc.net!gmd.de!Germany.EU.net!mcsun!sunic!ugle.unit.no!ugle!anders
  3. From: anders@lise11.lise.unit.no (Anders Christensen)
  4. Subject: Re: Capturing System Command Output (was: SH Backquote)
  5. In-Reply-To: Otto Stolz's message of Wed, 19 Aug 1992 18:17:10 MEZ
  6. Message-ID: <ANDERS.92Aug20021939@lise11.lise.unit.no>
  7. Sender: news@ugle.unit.no (NetNews Administrator)
  8. Organization: /home/flipper/anders/.organization
  9. References: <REXXLIST%92081920041037@DEARN>
  10. Date: 20 Aug 92 02:19:39
  11. Lines: 100
  12.  
  13. In article <REXXLIST%92081920041037@DEARN> Otto Stolz <RZOTTO@DKNKURZ1.BITNET> writes:
  14.  
  15. >                                   I'll not quote those parts I agree
  16. > with and have nothing to add to.
  17.  
  18. Sounds like a good custom. I'll try to do the same (hint hint)
  19.  
  20. > Apparently, Anders' examples assume that ls rather returns the filenames
  21. > one per word;
  22.  
  23. Oops, sloppy programming by me. My only excuse is that I was trying
  24. to show a point rather than constructing a program (did that sound
  25. convincing? :-)
  26.  
  27. > > 1) CALLED AS A FUNCTION
  28. > >       files = 'ls'(directory)
  29.  
  30. I'm becoming increasingly convinced that this might not be a very good
  31. idea, and that this syntax should be reserved for external Rexx
  32. functions (and programs pretending to be such.) You listed a few of
  33. the potential problems, and there are several more, too. 
  34.  
  35. > > 2) EXTRA TERM IN COMMANDS [to] redirect the output [to] the stack:
  36.  
  37. I have since read Ed Spire's article on the ANSI REXX committee's
  38. thoughts about the problem. I fell instantly in love with that syntax.
  39. As you points out, similar syntax has already been implemented in several
  40. environments:
  41.  
  42. > This is actually implemented
  43. > - in OS/2 as "| rxstack",
  44. > - in Personal REXX as ">STK:",
  45. > - in CMS as "( LIFO", "( FIFO", or "( STACK" -- though only for
  46. >   particular commands,
  47. > - and in CMS Rel 7 (and older CMS Releases with CMS-Pipes added) as
  48. >   "PIPE cms" ... "| stack", as in
  49.       "PIPE cms ls" directory "| stack".
  50.  
  51. but none of these seem as "Rexx'ish" the one suggested by Ed Spire. It
  52. was more or less what I was looking for :-)
  53.  
  54. But, it does not address the problem of what to do with the standard
  55. error (or other standard I/O streams.)
  56.  
  57. > > 3) READING COMMANDS WITH LINEIN.  A command is started with a builtin
  58.  
  59. > How will the interaction between the REXX program and its environment
  60. > (or environments) be handled, in this scheme? 
  61.  
  62. What about the following:
  63.  
  64.    rcode = popen( 'prog',, "prog-input", "prog-output" )
  65.    firstline = linein( 'prog-output' )
  66.    if (firstline == 'something') then
  67.       call lineout 'prog-input', 'input to prog'
  68.    /* etc */
  69.  
  70. Then popen() would create both a input output (transient) stream
  71. (which of course could be the same stream, too.) Depending on the
  72. contents of the output of 'prog' you can feed it with the appropriate
  73. input. 
  74.  
  75. Disadvantage: Yes, I know, the syntax above is terrible, and it isn't
  76. at all easy to read. On the other hand. It extends the concept of a
  77. stream to the communication with a running process. This is hardly a
  78. very big step, since streams don't have to be persistent (file-type of)
  79. streams. Actually, I believe some implementation have already done
  80. that. 
  81.  
  82. > The basic idea is an explicit binding of the command output (from any
  83. > environment) to a linein-stream; the particular syntax is negotiable :-)
  84.  
  85. Yes, I like the concept, and if the syntax could be negotiated into
  86. something compatible with the proposed ADDRESS clause mentioned above,
  87. I like the syntax too :-)
  88.  
  89. On the CMS issues, I stand corrected. It is far too long since I used
  90. CMS, and I really shouldn't pretend that I remember anything :-(
  91.  
  92. > Remaining discrepancies:
  93. > Even if one or several of the methods outlined above would become
  94. > standard, REXX programs could not be more portable than their environ-
  95. > ments would allow them to be! (viz. virtually not portable :-( )
  96.  
  97. Even if Rexx scripts aren't portable, Rexx users could take their
  98. knowledge of Rexx to another platform. Having a common macro
  99. processing language on multiple machine platforms and applications,
  100. sounds like a big winner to me. That is the most important use for a
  101. common syntax. The other important use is to get a common syntax for
  102. all implementation on one platform (ref: at least four Unix
  103. interpreters using different syntax.)
  104.  
  105. > The only way for the REXX programmer to strive for portability is to
  106. > invent his or her own, system independend, set of primitives, implement
  107. > them seperately for every system the programs are intended for, and use
  108. > them in the rest of the programs in a system independend way.
  109.  
  110. But, suppose that set of primitives was a part of Rexx ... ?
  111.  
  112. -anders
  113.