feat(cli): answer --help with the option list #114

Merged
binjovi-bot merged 5 commits from feat/help-flag into trunk 2026-09-13 18:15:33 +00:00
Owner

zelnet --help printed zelnet: unknown flag '--help' to stderr and exited 1. That is the first thing a person types after they install the package, and nothing in the repository mentioned a help flag.

--help and -h now print the option list on stdout and exit 0, so a shell can pipe it. An unknown flag keeps its loud stderr failure, which 0.10.2 deliberately added. --version still prints the build banner, which reports the protocol tables rather than the options.

build.zig runs the real executable for both flags and asserts the usage line on stdout with an empty stderr, the same contract --version has had since v0.10.4. Verified red before the change: both runs failed, with all 1015 unit tests passing.

The README OPTIONS table also gains the --ccsid row. The terminal has always accepted --ccsid, and it was described only in prose far below while every other flag was listed.

make ci passes: format check, unit tests, ReleaseSafe tests and the Binjovi package-entry contract.

$ zelnet --help
zelnet v0.10.3-dev — unified IBM terminal client (TN5250 + TN3270)

usage: zelnet <host> [port]   Connect a terminal session. The default port is 23.
       zelnet <verb> ...      IBM i Host Server: auth, cmd, sql, ifs, dq, xfer, pgm.

terminal options:
  --tls, --no-tls     Force the transport. By default, zelnet uses TLS on port 992 only.
  --ccsid <n>         Set the display code page by CCSID. The default is 37.
  --help, -h          Print this text. Then exit.
  --version, -v       Print the build banner. Then exit.

https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6

`zelnet --help` printed `zelnet: unknown flag '--help'` to stderr and exited 1. That is the first thing a person types after they install the package, and nothing in the repository mentioned a help flag. `--help` and `-h` now print the option list on stdout and exit 0, so a shell can pipe it. An unknown flag keeps its loud stderr failure, which `0.10.2` deliberately added. `--version` still prints the build banner, which reports the protocol tables rather than the options. `build.zig` runs the real executable for both flags and asserts the usage line on stdout with an empty stderr, the same contract `--version` has had since `v0.10.4`. Verified red before the change: both runs failed, with all 1015 unit tests passing. The README OPTIONS table also gains the `--ccsid` row. The terminal has always accepted `--ccsid`, and it was described only in prose far below while every other flag was listed. `make ci` passes: format check, unit tests, ReleaseSafe tests and the Binjovi package-entry contract. ``` $ zelnet --help zelnet v0.10.3-dev — unified IBM terminal client (TN5250 + TN3270) usage: zelnet <host> [port] Connect a terminal session. The default port is 23. zelnet <verb> ... IBM i Host Server: auth, cmd, sql, ifs, dq, xfer, pgm. terminal options: --tls, --no-tls Force the transport. By default, zelnet uses TLS on port 992 only. --ccsid <n> Set the display code page by CCSID. The default is 37. --help, -h Print this text. Then exit. --version, -v Print the build banner. Then exit. ``` https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6
feat(cli): answer --help with the option list
Some checks reported errors
binjovi/ci A newer source or plan superseded this Build
e990144ec6
zelnet had no help flag. `zelnet --help` printed "unknown flag" to stderr
and exited 1, which is the first thing a person types after they install
the package.

--help and -h now print the option list on stdout and exit 0, so a shell
can pipe it. An unknown flag keeps its loud stderr failure. The build runs
the real executable for both flags, as it already does for --version.

The README OPTIONS table gains the --help row and the --ccsid row. The
terminal has always accepted --ccsid, and the table listed every other
flag.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6
docs: name the source of the --help option list
Some checks failed
binjovi/ci Binjovi failed the frozen plan
59c05df194
The option list --help prints is the one the README OPTIONS table
documents. Say so, so the two stay together.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6
chore: rebuild against the repinned toolchain
Some checks reported errors
binjovi/ci A newer source or plan superseded this Build
74eafd9c34
The catalog now pins zig-builder v10, whose xar works on ARM64. The
previous build packaged both Linux architectures and then failed in the
macOS .pkg step.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6
chore: rebuild on the v10 toolchain catalog
Some checks failed
binjovi/ci Binjovi failed the frozen plan
ff35fe8957
The last build was planned thirteen seconds after the catalog release,
before the plan bundle poller made the new bundle active, so it ran on
zig-builder v9 and failed in xar again.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6
fix(ci): run the Linux self-check on a binary this machine can execute
All checks were successful
binjovi/ci Binjovi completed the frozen plan
75fc6efdee
The release script builds both Linux architectures and then runs one of
them to confirm the reported version. It named the amd64 binary. The
fleet is arm64 only and has no emulation, so that binary cannot start.

The refusal was silent. The command substitution captured the exec error
into the variable, and `set -e` ended the background subshell before the
comparison, so `fail` never ran. The build log showed four finished
packages and then only "one or more platform builds failed".

The self-check now reads `uname -m` and runs the matching binary, and it
reports a start failure on its own.

The contract test also gains a `refuse` helper. A plain `! grep` turns
errexit off for that one command, so both negated assertions passed
whether or not the text they refuse was present.

Claude-Session: https://claude.ai/code/session_01XdBRc9CHgFhAxCyHbdVtt6
binjovi-bot deleted branch feat/help-flag 2026-09-13 18:15:33 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
sean/zelnet!114
No description provided.