Summary
The - sentinel for reading a content argument from stdin works for some content-accepting commands but not others. Where it isn't supported, - is silently treated as literal content rather than either reading stdin or erroring — so a piped body is dropped and a malformed post is created.
I'd like - (stdin) to work uniformly across every command that takes a content/body positional.
Repro
printf '%s\n' 'First paragraph.' '' 'Second paragraph.' \
| basecamp messages create "Title" - --draft --in <project>
Expected: the message body is the piped multi-paragraph content (as comments create <id> - already does).
Actual: stdin is ignored, - is taken as the literal body, and the message renders as a single empty bullet:
<ul dir="auto">
<li>
</li>
</ul>
comments create accepts - for stdin; messages create (and, as far as I can tell, the other content-taking commands) do not.
Why this matters
- Least surprise / consistency.
- already means stdin on comments create. It's reasonable to expect it everywhere a content/body argument is accepted; the current split is an invisible footgun.
- Scriptability. Piping generated or multi-paragraph content is the natural way to post from automation. Without stdin, callers must inline the whole body as a shell argument.
- Portable quoting. The docs already warn that ANSI-C
$'...\n...' quoting is non-portable under a POSIX /bin/sh (a literal $/\n leaks into the post). stdin is the clean, portable escape hatch for multiline and non-ASCII bodies — but only if it works uniformly.
- Fail loud. At minimum, a command that doesn't support
- should error, not silently post a literal -. Silent literal-- is the worst of the three outcomes.
Proposed scope
Every command with a content/body positional should accept - to read that argument from stdin, matching comments create:
messages create / messages updatecards create / cards updatetodos create / todos update --descriptionfiles doc create / files updatechat postcheckins answer create
Ideally this is one shared argument-reader so new commands inherit it for free, with a single documented rule: any content positional accepts - for stdin.
Summary
The
-sentinel for reading a content argument from stdin works for some content-accepting commands but not others. Where it isn't supported,-is silently treated as literal content rather than either reading stdin or erroring — so a piped body is dropped and a malformed post is created.I'd like
-(stdin) to work uniformly across every command that takes a content/body positional.Repro
Expected: the message body is the piped multi-paragraph content (as
comments create <id> -already does).Actual: stdin is ignored,
-is taken as the literal body, and the message renders as a single empty bullet:comments createaccepts-for stdin;messages create(and, as far as I can tell, the other content-taking commands) do not.Why this matters
-already means stdin oncomments create. It's reasonable to expect it everywhere a content/body argument is accepted; the current split is an invisible footgun.$'...\n...'quoting is non-portable under a POSIX/bin/sh(a literal$/\nleaks into the post). stdin is the clean, portable escape hatch for multiline and non-ASCII bodies — but only if it works uniformly.-should error, not silently post a literal-. Silent literal--is the worst of the three outcomes.Proposed scope
Every command with a content/body positional should accept
-to read that argument from stdin, matchingcomments create:messages create/messages updatecards create/cards updatetodos create/todos update --descriptionfiles doc create/files updatechat postcheckins answer createIdeally this is one shared argument-reader so new commands inherit it for free, with a single documented rule: any content positional accepts
-for stdin.