home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / gnu / bash / bug / 657 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.9 KB  |  90 lines
  1. Newsgroups: gnu.bash.bug
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!hfrd.dsto.gov.au!dall
  3. From: dall@hfrd.dsto.gov.au (Ian Dall)
  4. Subject: Re: problem with bash + xon + sunos ...
  5. Message-ID: <1992Nov17.033736.8893@hfrd.dsto.gov.au>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: Defence Science and Technology Organisation
  8. References: <9211051448.AA24758.SM@odin.INS.CWRU.Edu>
  9. Distribution: gnu
  10. Date: Tue, 17 Nov 1992 03:37:36 GMT
  11. Approved: bug-bash@prep.ai.mit.edu
  12. Lines: 76
  13.  
  14.  
  15. In article <9211051448.AA24758.SM@odin.INS.CWRU.Edu>, chet@odin.ins.cwru.edu (Chet Ramey) writes:
  16. > This is a bug alright, but it's a bug with rshd that's not fixed until
  17. > 4.3-reno.
  18. > 
  19. > rshd sets up a pipe (int pv[2]; if you have the source to the tahoe rshd)
  20. > to the process it executes and uses it to manage error and control output
  21. > from over the net.  In the child process, it does a dup2(pv[1], 2), but
  22. > never calls close(pv[1]).  Adding that code to the 4.3-tahoe rshd makes it
  23. > (and the Xemacs script) work right.
  24. > 
  25. > I don't know how to solve this cleanly in bash.  Doing a blanket close of
  26. > all open file descriptors > 2, < 20 is a no-no, especially when we're not
  27. > interactive.  csh `works' because it does the blanket close on startup, but
  28. > csh can get away with doing that because it doesn't let you manipulate
  29. > arbitrary file descriptors.
  30.  
  31. At least on this machine the problem appears to be more that just one
  32. with rsh. For years I have been using the exec n>&- trick to fix the
  33. rsh problem. (Where n is the problem file desciptor). With the
  34. current version of bash, that doesn't seem to work.
  35.  
  36. I have a program called "nfiledes" which figures out what file desciptors
  37. are open:
  38.  
  39.     cronus:-dall $ bash
  40.     cronus:-dall $ exec nfiledes
  41.     File descriptor 5 open.
  42.     File descriptor 2 open.
  43.     File descriptor 1 open.
  44.     File descriptor 0 open.
  45.     4 file descriptors open across execs.
  46.     cronus:-dall $ bash
  47.     cronus:-dall $ exec nfiledes 5>&-
  48.     File descriptor 10 open.
  49.     File descriptor 2 open.
  50.     File descriptor 1 open.
  51.     File descriptor 0 open.
  52.     4 file descriptors open across execs.
  53.  
  54.  
  55. Note that as soon as I try and close file desciptor 5, something (and
  56. I can't think how it could be anything except bash) opens a new file
  57. descriptor (10). (And if I close 10 it opens 11).
  58.  
  59.  
  60. This is
  61.     BASH_VERSION=1.12.1
  62.  
  63. on a DECstation 5000 (mips R3000) running Ultrix 4.2.
  64.  
  65. Here is the source for nfiledes.c
  66.  
  67. /* Count the number of file descriptors currently open */
  68. #include <stdio.h>
  69. #include <fcntl.h>
  70. main ()
  71. {
  72.   int ret, i, n = 0;
  73.   for ( i = _NFILE; i--;)
  74.     if ( (ret = fcntl(i, F_GETFD, 0)) != -1)
  75.       {
  76.     printf("File descriptor %d open.\n", i);
  77.     n += (!ret) & 1;
  78.       }
  79.   printf("%d file descriptors open across execs.\n", n);
  80. }
  81.  
  82.  
  83. Ian
  84. -- 
  85. Ian Dall          I'm not into isms, but hedonism is the most
  86.                   harmless I can think of. -- Phillip Adams
  87.  
  88. internet: dall@hfrd.dsto.gov.au
  89.  
  90.