home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / gnu / bash / bug / 647 < prev    next >
Encoding:
Text File  |  1992-11-07  |  3.1 KB  |  73 lines
  1. Newsgroups: gnu.bash.bug
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sun-barr!ames!saimiri.primate.wisc.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!odin.ins.cwru.edu!chet
  3. From: chet@odin.ins.cwru.edu (Chet Ramey)
  4. Subject: Re: problem with bash + xon + sunos ...
  5. Message-ID: <9211051448.AA24758.SM@odin.INS.CWRU.Edu>
  6. Sender: gnulists@ai.mit.edu
  7. Reply-To: chet@po.cwru.edu
  8. Organization: GNUs Not Usenet
  9. References: chet@odin.ins.cwru.edu (Chet Ramey)
  10. Distribution: gnu
  11. Date: Thu, 5 Nov 1992 04:48:35 GMT
  12. Approved: bug-bash@prep.ai.mit.edu
  13. Lines: 58
  14.  
  15. > I have `bash' as my standard login shell under sunos 4.1.1 and I am
  16. > trying to use the X11 R5 script `xon' that allow to create an xterm
  17. > on a remote machine using your local display.  Has anybody noticed
  18. > that on the sun the xon script keep the connection open until the 
  19. > remote xterm dies.
  20. > 
  21. > The xon script does something like this:
  22. > 
  23. >   rsh remotehost "sh -c 'DISPLAY=currentdisplay:0.0 xterm -ls >/dev/null \
  24. >   2>&1 &'"
  25. > 
  26. > This should run the remote xterm in the background at the remote host.
  27. > 
  28. > If your login shell is bash then the rsh command hangs until the remote
  29. > xterm dies.  If your login shell is csh or your remote host is not 
  30. > running sunos (e.g. rs6000 running bash) then the xon command terminate
  31. > immediatly without waiting for the remote xterm to die.
  32.  
  33. It's a bug in rsh that Sun has not yet fixed.  Here's a message I sent to
  34. the IBM guy who had the same problem (which is why it's fixed in AIX):
  35.  
  36. Date: Sat, 27 Apr 91 19:31:16 -0400
  37. From: Chet Ramey <chet@odin.INS.CWRU.Edu>
  38. To: bfox@ai.mit.edu
  39. Subject: Re: [pedz@aixwiz.austin.ibm.com: fd 9 left open bug]
  40. Cc: chet@odin.INS.CWRU.Edu, pedz@aixwiz.austin.ibm.com
  41.  
  42. > Below is something I call Xemacs which goes across the net, sets up the
  43. > display variable and then kicks off emacs in such a way that rshd
  44. > terminates.  The trick is that the shell must die and all file
  45. > descriptors going back to rshd must be closed.  The same basic script
  46. > works with csh but I had to add in the "9>&-" part at the end to make
  47. > it work with bash.   This is because somehow, file descriptor 9 is left
  48. > open and I guess it must be a dup of stdin, stdout, or stderr.
  49.  
  50. This is a bug alright, but it's a bug with rshd that's not fixed until
  51. 4.3-reno.
  52.  
  53. rshd sets up a pipe (int pv[2]; if you have the source to the tahoe rshd)
  54. to the process it executes and uses it to manage error and control output
  55. from over the net.  In the child process, it does a dup2(pv[1], 2), but
  56. never calls close(pv[1]).  Adding that code to the 4.3-tahoe rshd makes it
  57. (and the Xemacs script) work right.
  58.  
  59. I don't know how to solve this cleanly in bash.  Doing a blanket close of
  60. all open file descriptors > 2, < 20 is a no-no, especially when we're not
  61. interactive.  csh `works' because it does the blanket close on startup, but
  62. csh can get away with doing that because it doesn't let you manipulate
  63. arbitrary file descriptors.
  64.  
  65. Chet
  66.  
  67. --
  68. ``The use of history as therapy means the corruption of history as history.''
  69.     -- Arthur Schlesinger
  70.  
  71. Chet Ramey, Case Western Reserve University    Internet: chet@po.CWRU.Edu
  72.  
  73.