fix(test): spawn the emulator test harness via an absolute /bin/sh

[zackees]

Symptom

Check (ubuntu-latest) failed on #1384 — a PR that touches none of this:

handlers::emulator::tests_process::run_avr8js_headless_halt_on_error ... FAILED
called `Result::unwrap()` on an `Err` value: DeployFailed(
  "failed to launch QEMU at sh: No such file or directory (os error 2).
   The cached QEMU toolchain may be incomplete or corrupt. On Linux/macOS,
   also ensure runtime deps are installed: libgcrypt, glib2, pixman, SDL2,
   and libslirp.")

No QEMU is involved

test_process_command builds a fake process that prints canned lines, so the
monitor logic can be tested without an emulator. On Unix it returned a bare
sh, left for the runtime to resolve through PATH:

(PathBuf::from("sh"), vec!["-c".to_string(), script])

When that lookup misses, the spawn failure surfaces through the QEMU launch
path — so a PATH problem in the test harness is reported as a corrupt emulator
toolchain, complete with advice to install pixman and SDL2. Anyone debugging
this from the message alone would go a long way in the wrong direction.

Fix

The Windows branch of the same function already builds an absolute path:

let exe = PathBuf::from(system_root).join(r"System32\cmd.exe");

The Unix branch just never did. POSIX requires /bin/sh, so naming it outright
removes the runner's environment from the equation rather than hoping PATH is
well-formed in whatever context the test binary runs.

Grepped the workspace: this was the only bare-program spawn of its kind.

Scope

Deliberately narrow. The misleading error message — a spawn failure reported
as "the cached QEMU toolchain may be incomplete or corrupt" — is a real
separate problem worth fixing, since it will mislead on genuine spawn failures
too. It belongs in its own change against the deploy error path, not bundled
into a one-line test-harness fix.

Verified: soldr cargo test -p fbuild-daemon --lib tests_process — 9 passed,
clippy -D warnings clean. I cannot reproduce the PATH miss locally (Windows
host), so the argument here is that the fix removes the dependency the failure
was on, not that I watched it go from red to green.

[coderabbitai]

Warning

Review limit reached

Next included review available in 32 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: b65daa82-e674-4280-97b6-d848ad18f866

📥 Commits

Reviewing files that changed from the base of the PR and between 9f82da3 and 153b89f.

📒 Files selected for processing (1)

• crates/fbuild-daemon/src/handlers/emulator/tests_process.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}