[212_2703] Fix gs path quoting for paths with spaces on macOS

[dorodb-web22]

Problem

On macOS, MoganSTEM fails to render PS/EPS images when the temp path contains
spaces (e.g., when the user's full name has a space, like /var/folders/.../John Doe/...).
Ghostscript receives malformed arguments and cannot process the file.

Closes #2703

Root Cause

sys_concretize(url) calls escape_sh(concretize(url)), which on macOS/Linux
backslash-escapes spaces:

gs -sOutputFile=/tmp/path\ with\ spaces/file.eps

The shell correctly passes standalone args with backslash-escapes, but Ghostscript
parses its own option values (-sOutputFile=..., -sFile=..., --permit-file-read=...)
as raw strings — it does not re-interpret shell backslash escapes. So GS splits
at the space and receives a malformed path.

Fix

Replace sys_concretize(url) with raw_quote(concretize(url)) at all path-in-option
sites in gs_utilities.cpp. Double-quoting passes the full path as one token:

gs -sOutputFile="/tmp/path with spaces/file.eps"

This is consistent with gs_prefix(), which already uses raw_quote(gs_executable())
on Windows for the same reason.

Changed functions: gs_image_size, gs_PDFimage_size, gs_to_eps, gs_to_ps, tm_gs.

How to Test

1. Build and run: xmake build stem && xmake run stem
2. Insert a PS/EPS image via Insert → Image
3. Verify it renders correctly (no blank/error on paths with spaces)

[Copilot]

Pull request overview

Fixes Ghostscript command-line construction so PS/EPS rendering works on macOS when temp paths contain spaces (e.g., user home paths like .../John Doe/...).

Changes:

• Replace sys_concretize(url) with raw_quote(concretize(url)) for Ghostscript file paths in gs_utilities.cpp.
• Update the Ghostscript PDF size probing path to quote $TEXMACS_PATH/misc/convert/pdf_info.ps.
• Add a developer note (devel/212_2703.md) describing the issue, rationale, and test steps.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
src/Plugins/Ghostscript/gs_utilities.cpp	Updates how file paths are embedded in Ghostscript command strings to handle spaces.
devel/212_2703.md	Documents reproduction, fix rationale, and manual test procedure for #2703.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

raw_quote(concretize(image)) is not shell-safe on macOS/Linux: raw_quote just wraps in double quotes and does not escape $, backticks, or ". Since lolly::system::call uses wordexp(..., flags=0) (command substitution enabled), a crafted filename could trigger expansion/command execution. For positional file args, sys_concretize(image) already handles spaces via backslash-escaping while also escaping metacharacters; consider keeping sys_concretize here and only changing the truly GS-option-value cases, or introduce a dedicated safe quoting/escaping helper for wordexp.

Suggested change

	cmd << raw_quote (concretize (image));
	cmd << sys_concretize (image);

[Copilot]

raw_quote(concretize(eps)) does not escape $/backticks/" and is therefore not safe to embed in a command string that is later parsed by wordexp (used by lolly::system::call on macOS/Linux). This is a potential command-injection vector via crafted filenames/paths. Please use a shell-safe quoting/escaping routine for paths here (or avoid string-based command parsing altogether).

[Copilot]

The new raw_quote(concretize(ps/doc)) usage is not safe with the current subprocess implementation on macOS/Linux: raw_quote does not escape $, backticks, or embedded quotes, and lolly::system::call uses wordexp with command substitution enabled. A malicious filename could be expanded/executed. Please switch to a shell-safe quoting approach (or pass argv without wordexp).

[Copilot]

raw_quote(concretize(image)) is not a safe way to quote a path for execution on macOS/Linux because raw_quote does not escape $/backticks/", and lolly::system::call uses wordexp (command substitution enabled). This allows command substitution if an image path contains $(...)/backticks. Please use a shell-safe quoting/escaping function for paths passed to subprocesses.

[dorodb-web22]

@MoonL79
GitHub Copilot flagged all the raw_quote(concretize(...))
calls as potentially unsafe , raw_quote only wraps in double quotes without escaping
$ or backticks, and lolly::system::call uses wordexp(..., 0) on macOS/Linux
(no WRDE_NOCMD), so a crafted filename with $(...) could in theory trigger expansion.

I'm inclined to keep the current approach because:

1. These are system-generated temp paths, not user-supplied filenames , no realistic
   injection vector.
2. raw_quote is already used in gs_prefix() on Windows for the GS executable,
   so this is consistent with existing patterns.

That said, if u would prefer a more conservative approach, I can limit raw_quote to
just the GS option-value sites (-sOutputFile=, -sFile=, --permit-file-read=)
where spaces actually break parsing, and revert standalone file path args back to
sys_concretize. Happy to do either.

[MoonL79]

Thank you for your work! I will get back to you today.

[MoonL79]

Thanks for the clarification. I agree the space-in-path bug is real and your change fixes that behavior for GS option values.

My concern is the security regression: raw_quote(concretize(...)) only adds double quotes, and on macOS/Linux our command path still goes through wordexp(..., 0), so
$() / backticks can still expand. I don’t think we should rely on “system-generated temp paths” as a hard trust boundary.

Could you please update this to a shell-safe + GS-safe approach instead of plain raw_quote?

At minimum, please add/cover cases for paths containing: space, $, backticks, ", ', and , for both standalone args and -sOutputFile= / -sFile= / --permit-file-read=forms.

[dorodb-web22]

@MoonL79 Thanks, that makes sense. I agree we shouldn't rely on temp paths as a trust boundary.

i have pushed an update addressing this. I added a new gs_path_quote helper function that wraps the path in double quotes (to preserve spaces for Ghostscript) but also explicitly escapes $, backticks, ", and \ inside.

This ensures wordexp won't expand or execute anything if those characters appear in the path, while properly handling spaces in both standalone args and the -sOutputFile= forms.

Please let me know if there's anything else you'd like me to change!