home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / shell / 3751 < prev    next >
Encoding:
Text File  |  1992-09-01  |  2.5 KB  |  75 lines
  1. Newsgroups: comp.unix.shell
  2. Path: sparky!uunet!ftpbox!mothost!merlin.dev.cdx.mot.com!fendahl.dev.cdx.mot.com!mcook
  3. From: mcook@fendahl.dev.cdx.mot.com (Michael Cook)
  4. Subject: Re: rshing Ultrix xterms
  5. Message-ID: <mcook.715394232@fendahl.dev.cdx.mot.com>
  6. Sender: news@merlin.dev.cdx.mot.com (USENET News System)
  7. Nntp-Posting-Host: fendahl.dev.cdx.mot.com
  8. Organization: Motorola Codex, Canton, Massachusetts
  9. References: <1992Sep1.192315.24302@iscnvx.lmsc.lockheed.com>
  10. Date: Wed, 2 Sep 1992 00:37:12 GMT
  11. Lines: 62
  12.  
  13. rahner@iscnvx.lmsc.lockheed.com (Mark Rahner) writes:
  14.  
  15. >Hello World,
  16.  
  17. >I am having trouble rshing an xterm when the remote xterm is started
  18. >under Ultrix V4.2 (Rev. 96) UWS V4.2 (Rev. 272).  Specifically, I can't
  19. >prevent rsh from hanging around until the remote xterm has completed.
  20. >I am using the Korn shell on all of the networked systems.  It is
  21. >particularly important to me that the remote xterm be independent of
  22. >the local xterm.  That is, I must be able to terminate the local xterm
  23. >without affecting the remote xterm.
  24.  
  25. >And now, a preemptive quote from FAQ 3.2:
  26.  
  27. >> 2)  How do I use "rsh" without having the rsh hang around until the
  28. >>     remote command has completed?
  29. [...]
  30. >>
  31. >>         rsh machine -n 'command >/dev/null 2>&1 </dev/null &'
  32. >>
  33. >>     Why?  "-n" attaches rsh's stdin to /dev/null so you could run the
  34. >>     complete rsh command in the background on the LOCAL machine.
  35. >>     Thus "-n" is equivalent to another specific "< /dev/null".
  36. >>     Furthermore, the input/output redirections on the REMOTE machine
  37. >>     (inside the single quotes) ensure that rsh thinks the session can
  38. >>     be terminated (there's no data flow any more.)
  39.  
  40. I came across the same problem.  It seems that there are some stray file
  41. descriptors being left open somewhere along the line, and rshd is waiting on
  42. them.  My tests show that file descriptors 4, 6, 8, 10, 11 and 12
  43. (consistently) are left open (along with 0, 1 and 2, of course).
  44.  
  45. The workaround is to close these extra file descriptors.  You can try this:
  46.  
  47.   rsh machine -n 'foo >/dev/null 2>&1 </dev/null' \
  48.     '4>&- 6>&- 8>&- 10>&- 11>&- 12>&-'
  49.  
  50. but I had trouble finding a shell that would grok two-digit file descriptors
  51. (sh, sh5 and ksh didn't, but bash did).
  52.  
  53. Another workaround is to run your command like this:
  54.  
  55.   rsh machine closeall foo
  56.  
  57. where closeall is this:
  58.  
  59. #include <sys/param.h>
  60. #include <fcntl.h>
  61.  
  62. int main(int argc, char **argv)
  63. {
  64.     int i;
  65.  
  66.     for (i = 0; i < NOFILE; i++)
  67.         close(i);
  68.     open("/dev/null", O_RDONLY);
  69.     open("/dev/null", O_WRONLY);
  70.     dup(1);
  71.     execvp(argv[1], argv + 1);
  72. }
  73.  
  74. Michael.
  75.