home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 740 < prev    next >
Encoding:
Text File  |  1992-08-19  |  2.6 KB  |  72 lines

  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!darwin.sura.net!paladin.american.edu!auvm!DKNKURZ1.BITNET!RZOTTO
  3. X-Acknowledge-To: <RZOTTO@DKNKURZ1>
  4. Message-ID: <REXXLIST%92081920591274@DEARN>
  5. Newsgroups: comp.lang.rexx
  6. Date:         Wed, 19 Aug 1992 20:22:03 MEZ
  7. Sender:       REXX Programming discussion list <REXXLIST@UGA.BITNET>
  8. From:         Otto Stolz <RZOTTO@DKNKURZ1.BITNET>
  9. Subject:      Re: Capturing System Command Output (was: SH Backquote)
  10. In-Reply-To:  Message of Wed, 19 Aug 92 13:54:45 GMT from <jpr@HP10.LRI.FR>
  11. Lines: 59
  12.  
  13. On Wed, 19 Aug 92 13:54:45 GMT Jean-Pierre Riviere said:
  14. > Well, I am not a specialist but whatthe hell is the "RESULT" var done
  15. > for ?
  16.  
  17. According to TRL (Section 14), and other sources, RESULT will always
  18. hold the result of the REXX function finished most recently. Example:
  19.      say time()
  20. and
  21.      call time
  22.      say result
  23. are semantically equivalent.  (Though my test run resulted in a dis-
  24. crepancy in the least significant figures :-)
  25.  
  26. According to the same authoritative sources, the only variable affected
  27. by a command to an external environment, is RC. It will hold the return
  28. code of the command executed most recently.
  29.  
  30. In all operating systems I know of (admittedly not including Amiga), the
  31. return code is a different concept from the standard output of a command.
  32. Hence the current thread on how to grab the standard output *in addition
  33. to the rc*.
  34.  
  35. > Would not be the better way be
  36. > "ls -l ~"
  37. > dir = result
  38.  
  39. Definitely not, as this would invalidate many existing REXX programs,
  40. viz. programs that depend on the RESULT variable not being affected by
  41. a command to an external environment.
  42.  
  43. > (This is the only available way to do it with arexx btw)
  44.  
  45. Hardly believable! If indeed so, Arexx would be grossly non-standard.
  46. Please test your example, and report again.
  47.  
  48. > It's common rexx anf follows Cowlishaw's rules. (as far as I under-
  49. > stood it...)
  50.  
  51. Definitely not (cf. supra). You'd better read Cowlishaw again!
  52.  
  53. > So why are you trying to implement hassles with
  54. > dir = "ls -l ~"
  55. > and all its derivative ?
  56.  
  57. Nobody has proposed this variant, for the simple reason that it
  58. already has a meaning in REXX, quite different from what you seem to
  59. expect, viz. set the variable DIR to the value "ls -l ~".
  60.  
  61. > Cannot the result way be good enough for us ?
  62.  
  63. Apparently not, for reasons given above.
  64.  
  65. > Just a reflexion from a rexx user. Nothing else.
  66.  
  67. Francly, I wouldn't call it a reflexion ...
  68.  
  69. Best wishes,
  70.                     Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
  71.                                <RZOTTO@nyx.uni-konstanz.de>
  72.