Re: closing extra fd's in gnome_execute_*

[Manish Vachharajani <mvachhar vger rutgers edu>]

On 10 Jan 1999, Elliot Lee wrote:

> On Sat, 9 Jan 1999 13:05:18 -0500 (EST), Manish Vachharajani
> <mvachhar@vger.rutgers.edu> wrote:
> 
> >> Broke(tm) then this would constitute a bugfix ... it would be better to
> >> keep source compatibility and iron out the ugliness of the API later
> >> (after 1.0)
> >
> >Well, the question is, does anyone expect any fd's besides 0, 1, or 2 to
> >be open after executing gnome_execute_*.  If not then we can just close
> >all the additional fd's before execing.  I am pretty certain this is the
> >behavior most people expect.  I am curious to know if there are any
> >exceptions.  If people want them open, I can go ahead and add the new
> >functions.
> 
> There's no reason to close all the fd's. People sometimes want to open a
> pipe to a program or such - just leave it be...
> 
> If bash crashes, fix bash ;-)

I agree that bash should be fixed, but as I said before, I have seen this 
stupid select(SOME_FIXED_NUMBER,...) garbage in so many programs it isn't 
always practical to fix them all.  

Since you don't like the behavior though, I will add functions that will
not close the fd's.  There is no reason to have all these open files
around anyway.  It can become problematic if someone opens a large file
and it gets inherited.  If this happens, I can't delete it for instance if
my fs is full and regain the space.  What's worse is I may have no clue
who has it open.  For people that want to open pipes and such(just the
type of thing I was wondering if it was done or not with the current
stuff) they can use the new functions that I will add.  It seems most
people don't intend to keep the other fd's open anyway.

Manish Vachharajani               Some Haiku: A crash reduces
<mvachhar@vger.rutgers.edu>                   your expensive computer
                                              to a simple stone - Unknown