Re: ZSH_XTRACE_FILE (instead of ZSH_XTRACEFD)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, Mar 18, 2026 at 9:53 AM Charles Blake <charlechaud@xxxxxxxxx> wrote:
>
> I appreciate the cautious mindset, but I still think the analogy is
> inapt.  There is no new execution path here - only segregated
> destinations rather than smooshed together stderr and even then only
> when tracing is active.

Consider ZSH_XTRACE_FILE=$HOME/.zshenv for an example of where things
could go badly wrong.

> ZSH_XTRACEFD was discussed from 2019-05-17 all the way to 2020-05-05.
> This objection was not raised in spite of shell shock being much more
> recent at the time and main Zsh contributors participating.

That's quite possibly because ZSH_XTRACEFD does not suffer from the same issue.

With ZSH_XTRACE_FILE, the shell is being asked to perform an open()
system call on an arbitrary path, and then write to it.  This is
inherently dangerous in the context of e.g. a script that otherwise
would not take those actions.

With ZSH_XTRACEFD, the descriptor must already exist -- the
surrounding environment is tasked with opening files/pipes/etc. with
proper permissions, all zsh is required to do is write to the file.