---
name: a-heredoc-binds-to-the-last-command-of-an-or-chain
description: `cat > a || cat > b <<'EOF'` attaches the heredoc to the SECOND cat only; the first cat reads the tool's stdin and blocks for the full timeout, and the send that followed never fired
metadata:
  type: feedback
---

doyle 2026-09-10 01:19Z: wrote `cat > "$TMPDIR/x" 2>/dev/null || cat > "$S/x" <<'EOF' ... EOF; spt send emphasys < "$S/x"`.
The heredoc is a redirection on the LAST simple command of the `||` chain. The FIRST cat had no stdin
redirect, so it read the Bash tool's stdin (never closed) and hung 120 s; the tool moved it to the
background where it kept hanging; `spt send` never ran. Output was empty, not an error, so the failure
read as "slow", and I only noticed because the DISPATCH_RESULTS for that target never appeared.

**Why:** an unclosed stdin is a HANG, not a failure — no exit code, no stderr, nothing to grep. Any
command that MIGHT read stdin and is not the one the heredoc binds to will do this.

**How to apply:** one command per heredoc — write the file with a single `cat > "$S/x" <<'EOF'` (mkdir -p
the dir first, never `||` a fallback path in front of it), then send in a separate statement. If a
fallback is needed, branch with `if`, not `||`. After any Bash tool timeout on a "write then send"
line, treat the send as NOT FIRED and check DISPATCH_RESULTS / QUEUED-SENT output before resending.
Kin: [[backticks-in-a-double-quoted-message-body-execute]] (compose peer messages from files, but the
file write itself has its own trap), [[spt-shell-send-takes-arg-not-stdin]].