Hello, I'm coming back to the ZSH_XTRACEFD feature again :)

About closing file descriptors or not: I don't understand what it means to "leak a FILE".

I'm not sure to understand the past comments either: we only use fdopen when the value of ZSH_XTRACEFD is > 2.

For 0, 1 and 2, we re-use the existing file descriptors stdin, stdout and stderr.

Anyway, I added the patch in an attachment. Also, here's the link to the commit on my fork:

https://github.com/pawamoy/zsh/commit/b9b37333fcf02a463f6f742976b37b45ab08742d

In this patch, I never close any file descriptor.

There's one last thing that looks weird to me:

single instructions like ZSH_XTRACEFD=5 are not properly logged in the xtrace output.

It seems they are truncated up to the end of the variable assignment:

- with a=0 ZSH_XTRACEFD=5, nothing appear in the output either

- with ZXH_XTRACEFD=5 a=0, only a=0 appears in the output (but no +(eval):18 prefix or similar)

Any idea about this?

Cheers,

Timothée

On Wed, May 6, 2020 at 12:20 AM Bart Schaefer <schaefer@brasslantern.com> wrote:

(Peter, for some reason Gmail is classifying all email from
ntlworld.com as spam, with the notation that it "can't guarantee that
this message came from ntlworld.com")

On Tue, May 5, 2020 at 9:48 AM Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
>
> 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.

In that case we should be doing the fopen() on a dup() of the
descriptor, and fclose()ing the FILE.

If it is important that fileno(xtrerr) == $ZSH_XTRACEFD, then we should
1) dup() the descriptor to save a copy
2) fopen() the original
3) after fclose(), dup2() the copy back to the original
4) close() the copy

However, I'm not sure it's necessary to be that convoluted.