home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 758 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  2.2 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!uakari.primate.wisc.edu!doug.cae.wisc.edu!umn.edu!noc.msc.net!uc.msc.edu!apctrc!wsc!mozart!zjlc12
  2. From: zjlc12@hou.amoco.com (Jerry Campbell)
  3. Newsgroups: comp.lang.rexx
  4. Subject: Re: Capturing System Command Output (was: SH
  5. Message-ID: <1992Aug20.140814.6476@hou.amoco.com>
  6. Date: 20 Aug 92 14:08:14 GMT
  7. References: <19920819090033SEB1525@MVS.draper.com>
  8. Sender: news@hou.amoco.com
  9. Reply-To: zjlc12@hou.amoco.com
  10. Organization: Amoco
  11. Lines: 43
  12.  
  13. In article 19920819090033SEB1525@MVS.draper.com, SEB1525@MVS.draper.com (Steve Bacher) writes:
  14. >Just from the UI POV, how about a fifth:
  15. >
  16. >       rcode = queue_to_stack("ls" directory)
  17. >
  18. >and
  19. >
  20. >       rcode = dump_into_stem_vars("ls" directory, "STEMPREFIX.")
  21. >
  22. >(Choose your own function names - these are for self-evidentness.)
  23. >
  24. >Similar syntactically to popen(), but captures stdout and puts it
  25. >on the data stack or in stem variables a la EXECIO.
  26. >
  27. >............................................... the programming
  28. >interface to get at the data should be in the REXX culture, not
  29. >the culture of the surrounding OS.  This would also get around
  30. >the "address something-other-than-the-native-shell" problem
  31. >you alluded to with the 'address ftp; "ls | rxqueue"' difficulty.
  32. >
  33. >.....
  34. >
  35. >No, a better solution would be to have one method.  Dispatching on
  36. >whether a particular syntax is used is just as bad as, and possibly
  37. >worse than, dispatching on a particular implememntation.
  38. >
  39. >--
  40. >Steve Bacher (Batchman)                 Draper Laboratory
  41. >Internet: seb@draper.com                Cambridge, MA, USA
  42.  
  43. I totally agree with Mr. Bacher.  I think the problem needs to be abstracted 
  44. from any operating system specifics.  In other words, set down a "standard"
  45. way of doing this from rexx programmer's point of view.  Something like 
  46. queue_to_stack() or whatever, something that is pure rexx and not tied to
  47. what kind of shell you're in.  If that can be agreed on then the ugly details
  48. of how to implement such a thing would be left to the language implementor.
  49. I believe that's where responsibility for implementation specifics of "standard"
  50. language features should reside.  
  51.  
  52. ---
  53. Jerry Campbell   reply to: zjlc12@hou.amoco.com 
  54. Amoco Corp. ISD  SSS/Graphics
  55. Houston, Tx.     713/556-7036
  56.