Re: ZSH_XTRACE_FILE (instead of ZSH_XTRACEFD)

[Mikael Magnusson <mikachu@xxxxxxxxx>]

@@ -314,6 +317,7 @@ IPDEF2("HOME", home_gsu, PM_UNSET),
 IPDEF2("TERM", term_gsu, PM_UNSET),
 IPDEF2("TERMINFO", terminfo_gsu, PM_UNSET),
 IPDEF2("TERMINFO_DIRS", terminfodirs_gsu, PM_UNSET),
+IPDEF2("ZSH_XTRACE_FILE", xtracefile_gsu, PM_UNSET),
 IPDEF2("WORDCHARS", wordchars_gsu, 0),
 IPDEF2("IFS", ifs_gsu, PM_DONTIMPORT | PM_RESTRICTED),
 IPDEF2("_", underscore_gsu, PM_DONTIMPORT),

This should probably be marked PM_DONTIMPORT so that you can't get zsh
to start spewing random text in any old file. (google shellshock for
why allowing this might be a bad idea)

@@ -1330,6 +1330,8 @@ setupvals(char *cmd, char *runscript, char *zsh_name)
             setsparam("ZSH_EXEPATH", metafy(mypath, -1, META_REALLOC));
         }
     }
+    if ((ptr = getsparam("ZSH_XTRACE_FILE")) && *ptr)
+        setsparam("ZSH_XTRACE_FILE", ztrdup(ptr));
     if (cmd)
         setsparam("ZSH_EXECUTION_STRING", ztrdup(cmd));
     if (runscript)

What's the point of this? If the parameter is set, set it to its
current value? This is presumably not needed if we don't allow
importing the parameter, right?

+/* gsu.getfn for `ZSH_XTRACE_FILE' */
+/* gsu.setfn for `ZSH_XTRACE_FILE' */
useless comments

+        /* No exec-inherit, append for logs, alternate tty log IS thinkable. */

On Wed, Mar 18, 2026 at 3:08 PM Charles Blake <charlechaud@xxxxxxxxx> wrote:
>
> So, there seems to have been a stalled patch effort from Timothée
> Mazzucotelli on ZSH_XTRACEFD back in September 2020.  Attached is a
> proposal that just uses a filename.  mkfifo is always an alternative
> for more complex scenarios, but having the interface be a simple path
> seems more user-friendly to me.
>
> The patch is small and includes both docs and tests.  It seems that
> the code to abstract `stderr` into `xtrerr` for trace log purposes
> has been around since a 2000-02-19 Peter Stephenson change.  This new
> ZSH_XTRACE_FILE variable seems like a natural conclusion to that work.
>
> I don't think there are any file descriptor leaks.  E.g., `for i in
> {1..50000};ZSH_XTRACE_FILE=/tmp/$i` works fine for me.  An off-to-
> the side strace shows no increase in file descriptor numbers during
> such.  As in the attached patch, the variable is not local-izable
> to shell functions.  This may be a minor annoyance but does not seem
> like a deal-breaker problem since, in some sense, fd 2 for a process
> is already an "even more global" destination (ultimately the very
> motivation for a new destination for trace logs!).
>
> Let me know if you see any problems.
>
> Best,
> cblake