TeX macro expansion engine and pdfTeX driver: \write18 shell-escape blocking under restricted mode

Interoperability boundary

The goal is to clarify how TeX’s macro expansion engine coordinates with the pdfTeX output driver when a \write18 shell-escape command spawns a long-running external process while the engine operates in the restricted shell-escape mode that became the default in 2020.

Constraints and uncertainty

Macro expansion proceeds independently of the backend; \write18 is expanded during token processing and triggers a shell call before any page is shipped out. pdfTeX buffers output until a page completes, so a blocking external command stalls the main TeX process, mimicking resource-exhaustion symptoms. Restricted mode causes \write18 to expand to empty text without error, silently dropping expected side-effects. Behavior differs across pdfTeX, XeTeX, and LuaTeX, and security policies can override the shell-escape setting at runtime.

Open questions

1. What observable log signatures distinguish a blocked \write18 call from genuine connection-pool exhaustion in a restricted-mode environment?
2. How should a build system reliably detect whether unrestricted shell escape is actually active, given that the ‘Shell escape enabled’ message may be suppressed or redirected?
3. Are there documented engine-specific timeouts or process-group behaviors that affect how long pdfTeX waits for a \write18 child before considering it a failure?