home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!csn!stortek!sanitas!pg
- From: pg@sanitas.stortek.com (Paul Gilmartin)
- Newsgroups: comp.lang.rexx
- Subject: Re: Capturing System Command Output (was: SH Backquote)
- Message-ID: <1992Aug28.234136.6485@stortek.com>
- Date: 28 Aug 92 23:41:36 GMT
- References: <1992Aug28.183336.15975@wrkgrp.COM>
- Sender: usenet@stortek.com
- Organization: Storage Technology Corp.
- Lines: 32
- Nntp-Posting-Host: sanitas.stortek.com
- X-Newsreader: Tin 1.1 PL5
-
- Edward T Spire (ets@wrkgrp.COM) wrote:
-
- : The nice thing about doing this kind of stuff exclusively with functions
- : is that it's easy to test (external functions) and you don't risk the
- : chance of damaging the language when you do it that way.
-
- Gee, That's _exactly_ the enhancement I'd like to see in the 'POPEN'
- built-in function of your employer's uni-REXX product. :-)
-
- : You would need to firm up this idea of using a program-specified
- : filename as a handle on an interprocess communications port, and think
- : about it's impact on the file namespace and accessibility to other
- : files, etc.
-
- How about:
- Handle = 'POPEN'(command, type) /* args as in the C function */
-
- The handle returned might well have a form such as:
- /dev/uni-REXX/process-id
-
- this should have minimal impact on the file namespace, since:
-
- uni-REXX is a registered trademark of The Workstation Group.
-
- : My impression is that it was no small feat to craft REXX so that it is
- : easy to use and powerful at the same time. I would not want to go
- : wading off on some large extensions like this without their being
- : carefully thought out and field tested.
-
- Agreed.
-
- -gil
-