Re: Feature request: ZSH_XTRACEFD variable

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

> On 05 May 2020 at 17:36 Timothée Mazzucotelli <timothee.mazzucotelli@gmail.com> wrote:
> 
> 
> > > I wrote such a test and noticed that file descriptors were being
> > > closed each time ZSH_XTRACEFD was (re)assigned, even as a local
> > > variable.  So I removed the code lines closing the previous file
> > > descriptor in xtracefdsetfn, and it seemed to work well.
> >
> > This re-introduces the file descriptor leak I was at pains to remove.
> > It apparently works because the test isn't sensitive to the leak ---
> > that's hard to fix in a standard way, i.e. with1out having some limit you
> > can rely on on file descriptors being created.
> 
> After thinking about it more, do we really want to close the file
> descriptors?
> I mean, when assigning ZSH_XTRACEFD, the file descriptor it points to
> must already exist, i.e. the users must create it themselves, explicitly.
> We never implicitly create file descriptors for this feature,
> so why would we implicitly close them?

The problem is if we fopen() the file descriptor to use stdio as output, we can either
leak the entire FILE, not opened by the user, or we can close the entire FILE.

That's unless you can get away with assigning fileno(file) an invalid file descriptor,
or there's some other interface I don't know about.

I don't think we want to go down the road of not using stdio for stderr, it seems
like too much of a waste.

pws