home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 734 < prev    next >
Encoding:
Text File  |  1992-08-19  |  3.2 KB  |  76 lines
  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!gatech!news.byu.edu!eff!sol.ctr.columbia.edu!usc!wupost!think.com!news.bbn.com!noc.near.net!ns.draper.com!news.draper.com!MVS.draper.com!SEB1525
  3. From: SEB1525@MVS.draper.com (Steve Bacher)
  4. Subject: Re: Capturing System Command Output (was: SH Backquote)
  5. Message-ID: <19920819090033SEB1525@MVS.draper.com>
  6. Sender: MVS NNTP News Reader <NNMVS@MVS.draper.com>
  7. Nntp-Posting-Host: mvs.draper.com
  8. Organization: Draper Laboratory
  9. References: <ANDERS.92Aug18223235@lise8.lise.unit.no>
  10. Date: Wed, 19 Aug 1992 14:00:00 GMT
  11. Lines: 63
  12.  
  13. In article <ANDERS.92Aug18223235@lise8.lise.unit.no>,
  14. anders@lise8.lise.unit.no (Anders Christensen) writes:
  15.  
  16. >The three different _conceptual_ methods that I am aware of are
  17. [following very abbreviated]
  18. >
  19. >      files = 'ls'(directory)
  20. >      'ls' directory ' >LIFO'     /* or "|rxstack" */
  21. >       'ls | rxstack'
  22. >      rcode = popen( "ls" directory,, "ls-output" )
  23.  
  24. Er, our *four* different conceptual methods...?
  25.  
  26. Just from the UI POV, how about a fifth:
  27.  
  28.        rcode = queue_to_stack("ls" directory)
  29.  
  30. and
  31.  
  32.        rcode = dump_into_stem_vars("ls" directory, "STEMPREFIX.")
  33.  
  34. (Choose your own function names - these are for self-evidentness.)
  35.  
  36. Similar syntactically to popen(), but captures stdout and puts it
  37. on the data stack or in stem variables a la EXECIO.
  38.  
  39. And what about stderr?  Maybe an optional third argument could
  40. specify the destination for stderr.  (Let's not get fancy and
  41. start specifying destinations for file descriptor numbers...)
  42.  
  43. I don't like the ">LIFO" syntax because that conflicts with a
  44. valid file-redirection spec, using up potential file names in
  45. a magic-cookie sort of way.  Also, this and the piping and popen
  46. solutions are too Unix-oriented in coding style; the programming
  47. interface to get at the data should be in the REXX culture, not
  48. the culture of the surrounding OS.  This would also get around
  49. the "address something-other-than-the-native-shell" problem
  50. you alluded to with the 'address ftp; "ls | rxqueue"' difficulty.
  51.  
  52. Implementation would probably involve the temporary redirection
  53. of stdout to somewhere where the output could be captured (e.g.
  54. a temporary file) and then unredirected at the end.  The user's
  55. default shell (or shell specified by "address", maybe?)  should be
  56. used to invoke the command.  In cases where the command string is
  57. simple enough to allow for it, the command could be executed directly
  58. (e.g. via system), but this should be done only when the results would
  59. transparently be the same.  (E.g. "cd" should fail to update the
  60. current directory as the REXX exec sees it, just as if it were shelled
  61. out, even if it wasn't.)
  62.  
  63. >A better solution might be to label the _methods_ rather than the
  64. >_interpreters_, then it would be possible to check whether an
  65. >interpreter supports e.g. the popen-based method. Then the user don't
  66. >have to update his rexxscripts to support new interpreters, but new
  67. >interpreters will support the already existing methods.
  68.  
  69. No, a better solution would be to have one method.  Dispatching on
  70. whether a particular syntax is used is just as bad as, and possibly
  71. worse than, dispatching on a particular implememntation.
  72.  
  73. --
  74. Steve Bacher (Batchman)                 Draper Laboratory
  75. Internet: seb@draper.com                Cambridge, MA, USA
  76.