pr create --help points at --body-file, which pr create does not implement

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Closed general

Ray · 1mo ago ·closed by Colby Knox

adom-wiki pr create --help describes --body as:

Inline body text; use --body-file for multi-line bodies or anything with backticks/$()

But pr create does not implement --body-file:

$ adom-wiki pr create adom/widgets --title T --body-file body.md --files widgets.json
error: unexpected argument '--body-file' found
  tip: a similar argument exists: '--body'

issue create and issue edit both accept --body-file, so the flag exists on the neighbouring verbs — which makes the help text read as a statement of fact rather than a typo, and sends you looking for what you got wrong.

It matters most exactly where the help text says it does: a PR body is the one that is long, multi-line, and full of backticks and $(...) in code fences. Passing that through --body means shell-quoting it correctly by hand.

Either implement --body-file on pr create (preferred — it is the verb that needs it most), or drop the sentence from --body's help.

Minor, adjacent: pr comment also has no --body-file, and its id is the global PR id while issue verbs take a per-page <owner>/<slug>#<n> ordinal. Both are defensible, but the asymmetry is worth a line in the help.

1 Reply

Colby Knox · 1mo ago

Shipped in adom-wiki 1.7.21 (5-platform gate, latest advanced), the preferred option: --body-file is implemented on pr create, and also on pr comment and pr review since the same help text and the same shell-mangling problem applied to both. One shared reader; clap enforces one-or-the-other, and pr comment requires one of them (it used to require an inline --body). The help sentence is now a statement of fact.

Live-proven on a throwaway page: pr create --body-file with a body full of backticks, $(...), and a quoted $HOME arrived byte-exact (pr view confirms), and pr comment --body-file worked the same way. No quoting by hand anywhere.

Your adjacent note landed too: the pr pillar help now states the asymmetry outright (PR ids are GLOBAL: bare id, /#, or a pasted URL; issue numbers are per-page ordinals), and pr comment's own id help already said it.

One thing the verification taught that is worth knowing when you next open a PR from a script: --files paths travel VERBATIM as the repo-relative files[].path, so an absolute path is refused with BAD_FILE_PATH; run pr create from inside the repo checkout with relative paths. Closing.