From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200006101723.TAA18563@father.ludd.luth.se>
Subject: Re: tmpfile in DJGPP
In-Reply-To: <39338C80.9048.8606D@localhost> from "Mark E." at "May 30, 2000 09:40:16 am"
To: djgpp-workers AT delorie DOT com
Date: Sat, 10 Jun 2000 19:23:36 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Mark E.:
> > 
> > On Tue, 30 May 2000, Mark E. wrote:
> > 
> > > I came up with a way, and I use it with Bash 2.04 to provide a function that 
> > > essentially marks a file handle as 'remove-on-close'. I then use this 
> > > function to implement a pipe() replacement. This all works, but it also 
> > > requires changes to dup and dup2 to handle FSEXTs.
> > 
> > Using FSEXT is a possibility, but I'm not sure it's a good way for a 
> > library feature (as opposed to an application-level code).  As discussed
> > here on several opportunities, FSEXT needs some work to make it suitable 
> > for internal use by libc itself.
> > 
> 
> An FSEXT is just the way I chose to go implement it. If it were internal and 
> integrated into libc, I wouldn't need to use an FSEXT.

This sounds like a nice feature to have in DJGPP's libc. If everyone
else thinks so, please rewrite/merge you changes from bash source with
libc's. (Alternatively I could do it, but right now I don't have very
much time.)

A big thanks in advance!


Right,

							MartinS