home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 756 < prev    next >
Encoding:
Text File  |  1992-08-20  |  2.6 KB  |  66 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: <1992Aug20.142314.19261@wrkgrp.COM>
  6. Organization: The Workstation Group
  7. References: <REXXLIST%92081920591274@DEARN>
  8. Date: Thu, 20 Aug 92 14:23:14 GMT
  9. Lines: 55
  10.  
  11. RZOTTO@DKNKURZ1.BITNET (Otto Stolz) writes:
  12. : On Wed, 19 Aug 92 13:54:45 GMT Jean-Pierre Riviere said:
  13. : > Well, I am not a specialist but whatthe hell is the "RESULT" var done
  14. : > for ?
  15. : 
  16. : According to TRL (Section 14), and other sources, RESULT will always
  17. : hold the result of the REXX function finished most recently. Example:
  18. :      say time()
  19. : and
  20. :      call time
  21. :      say result
  22. : are semantically equivalent.  (Though my test run resulted in a dis-
  23. : crepancy in the least significant figures :-)
  24. : 
  25. : According to the same authoritative sources, the only variable affected
  26. : by a command to an external environment, is RC. It will hold the return
  27. : code of the command executed most recently.
  28. : 
  29. : In all operating systems I know of (admittedly not including Amiga), the
  30. : return code is a different concept from the standard output of a command.
  31. : Hence the current thread on how to grab the standard output *in addition
  32. : to the rc*.
  33. : 
  34. : > Would not be the better way be
  35. : > "ls -l ~"
  36. : > dir = result
  37. : 
  38. : Definitely not, as this would invalidate many existing REXX programs,
  39. : viz. programs that depend on the RESULT variable not being affected by
  40. : a command to an external environment.
  41. : 
  42. : > (This is the only available way to do it with arexx btw)
  43. : 
  44. : Hardly believable! If indeed so, Arexx would be grossly non-standard.
  45. : Please test your example, and report again.
  46. : 
  47. : > It's common rexx anf follows Cowlishaw's rules. (as far as I under-
  48. : > stood it...)
  49. : 
  50. : Definitely not (cf. supra). You'd better read Cowlishaw again!
  51.  
  52. AREXX does contain some features that do not conform to Cowlishaw's
  53. rules.  In some cases this is somewhat understandable, such as the
  54. issue we're discussing here, where Cowlishaw gave no guidance, and each
  55. implementer was forced to roll his own.  In other areas (such as I/O)
  56. Bill Hawes simply did something he thought was better than what
  57. Cowlishaw had suggested.  He may have been "right" about that, but it
  58. is causing some problems in the ANSI REXX efforts.
  59.  
  60. ========================================================================
  61.  
  62. Ed Spire                           email: ets@wrkgrp.com      (on uunet)
  63. The Workstation Group              voice: 800-228-0255
  64. 6300 River Road, Suite 700            or  708-696-4800
  65. Rosemont, Illinois  60018            fax: 708-696-2277
  66.