home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / rexx / 823 < prev    next >
Encoding:
Text File  |  1992-08-29  |  3.7 KB  |  80 lines
  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!wrkgrp!ets
  3. From: ets@wrkgrp.COM (Edward T Spire)
  4. Subject: Re: Capturing System Command Output (was: SH Backquote)
  5. Message-ID: <1992Aug28.183336.15975@wrkgrp.COM>
  6. Organization: The Workstation Group
  7. References: <ANDERS.92Aug25012719@lise3.lise.unit.no>
  8. Date: Fri, 28 Aug 92 18:33:36 GMT
  9. Lines: 69
  10.  
  11. anders@lise3.lise.unit.no (Anders Christensen) writes:
  12. : In article <1992Aug24.150430.3770@wrkgrp.COM> ets@wrkgrp.COM (Edward T Spire) writes:
  13. : 
  14. : > : [ on the syntax   ADDRESS ... TO/FROM STREAM streamid ...]
  15. : 
  16. : > Note that the connections to REXX I/O streams simply replace the
  17. : > external data queue as a place to queue up input lines to be processed
  18. : > by the command and output from the command.  The command still runs
  19. : > synchronously, with no real interaction between the REXX program and
  20. : > the command. 
  21. : 
  22. : Why? The only thing needed in order to make this async, is to make the
  23. : environment aware that is should start the command in the background.
  24. : The "environment" in rexx is some slightly undefined entity which is
  25. : half inside the interpreter and half outside. At least under Un*x,
  26. : this could be done something like this:
  27. : 
  28. :    ADDRESS unix "cmd &" TO STREAM outdata FROM STREAM indata
  29. : 
  30. : Then, 'cmd' runs in the background, and 'outdata' and 'indata'
  31. : provides means to communicate with it. The interpreter controls the
  32. : execution of 'cmd' by either reading 'outdata' and writing 'indata'. 
  33. : 
  34. : Other operating system has different syntax to make commands run in
  35. : the background. Exactly how this is done is not really within the
  36. : domain of Rexx. But perhaps an extra subkeyword "ASYNC" should be
  37. : added, so that the interpreter itself knows explicitly that the
  38. : command should run in the background if possible. I am not so sure
  39. : about that.
  40. :
  41. : >              If you want the command to run asynchronously, so that the
  42. : > REXX program can see some of the command's output before deciding upon
  43. : > the rest of it's input, you'll probably want a function call-based
  44. : > approach.
  45. : 
  46. : Some environments are not really suited for async execution, i.e. they
  47. : cannot start a new command before the previous command is ended. In
  48. : these environments, the interpreter will have to be restricted to not
  49. : run another command before the previous was finished. 
  50. : 
  51. : I think the ADDRESS syntax is general enough to handle async commands
  52. : too. I don't want to use functions to start commands. The command
  53. : concept in Rexx is very elegant, and I want to use commands to perform
  54. : commands. I have nothing against using functions to _communicate_ with
  55. : the command running, but I'd like to start it as a command. 
  56.  
  57. Well, right off the top of my head, I see no reason why this could not
  58. be made to work.  However, it is a pretty long way from where we are now
  59. and it would have to be approached with some caution.
  60.   
  61. You would need to firm up this idea of using a program-specified
  62. filename as a handle on an interprocess communications port, and think
  63. about it's impact on the file namespace and accessibility to other
  64. files, etc.
  65.   
  66. You would need a set of functions to control the async process, tell
  67. what it's state is, is it waiting for input, kill it, notice it's
  68. termination, determine it's final return code, etc.
  69.   
  70. The nice thing about doing this kind of stuff exclusively with functions
  71. is that it's easy to test (external functions) and you don't risk the
  72. chance of damaging the language when you do it that way.
  73.  
  74. My impression is that it was no small feat to craft REXX so that it is
  75. easy to use and powerful at the same time.  I would not want to go
  76. wading off on some large extensions like this without their being
  77. carefully thought out and field tested.
  78.   
  79. -Ed
  80.