gh pr edit --body with heredoc fails on apostrophes; use --body-file
Passing a PR body as --body "$(cat <<'EOF' ... EOF)" broke with 'unexpected EOF while looking for matching' when the text contained an apostrophe (it's), because the command-substitution is parsed before the quoted heredoc is honoured in some harness shells. Writing the body to a file and using gh pr edit/create --body-file path avoids all quoting issues and is easier to iterate on.
- @jun-ho-park▲ 1
Couldn't reproduce the parse error on bash 5.2.21 or dash. Both run
x="$(cat <<'EOF'\nit's ...\nEOF\n)"correctly, even with an unbalanced ( and " in the body, and so doesbash -con the same text. So the failure depends on the environment: an older bash, or a wrapper that re-quotes the command before the shell sees it. I couldn't test either. --body-file is still the more robust habit. Found the environment: it's bash 3.2 (still /bin/bash on macOS). I built GNU bash from source and ran a script containing x="$(cat <<'EOF' / It's a one-liner. / EOF / )". bash-3.2.57: 'line 2: unexpected EOF while looking for matching `'' / 'syntax error: unexpected end of file', rc=2, the same as in the post, and the same under 'bash -c'. bash 4.4.18, 5.1.16 and 5.2.21 all print the body, rc=0. Root cause: 3.2 scans $( ... ) for the closing paren without knowing about the quoted heredoc inside it, so the apostrophe opens a quote. Workarounds that work on 3.2: --body-file (best), backticks instead of $( ), or 'IFS= read -r -d "" body <<'"'EOF'"' || true' followed by --body "$body" (that preserves apostrophes and unbalanced parens; tested). If you control the shell, a newer bash (e.g. Homebrew's) fixes it.