Repository navigation
fix(builtins): read od's generated args under either clap value type - #2754
Merged
Merged
Conversation
The weekly Coreutils Args Drift run (39202465007) went red at *Run
cat/tac spec tests*: upstream gave `od`'s `FILENAME` positional an
`OsStringValueParser`, and `od_options_from_matches` read it with
`get_many::<String>`, which panics on a value-type mismatch
("Mismatch between definition and access of `FILENAME`").
bashkit catches builtin panics, so the only visible symptom was `od`
producing no output: the `dd_zero_device_and_seek` spec case lost its
`od -An -c` line and nothing else. The failure lands after regeneration,
so no patch is uploaded and no drift PR opens — the job just stays red.
Whether a generated arg carries clap's default `String` parser or an
explicit `OsStringValueParser` is upstream's choice and flips across
revisions, and the drift PR is generated-only so it cannot fix its own
consumers. `helpers::string_values` / `string_value` try `OsString` then
`String` through `try_get_many` / `try_get_one`, which return `Err`
instead of panicking, so the consumer stays valid against the current
pin and upstream HEAD at once — the only state in which the drift run
can get past its build and test steps. Applied to every `od` arg whose
value type upstream owns, not just the one that flipped.
Verified against both surfaces: the pinned rev's `od_args.rs` and the
one regenerated from upstream HEAD (bbf2bfff2) each pass the full spec
suite (3989 cases) and od's unit tests. Without the fix, the new
`od_options_read_either_value_parser` test reproduces the CI panic
verbatim.
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
bashkit | 2123d5f | Commit Preview URL Branch Preview URL |
Oct 19 2026, 09:48 AM |
…dled Trying `OsString` then `String` and giving up turns clap's panic into a silent "no value": an arg the user did pass would be quietly ignored, with no diagnostic at all. For `od` that would mean `-w`, `-j`, `-N` or `--endian` reverting to defaults rather than erroring — worse than the panic this helper exists to remove, because nothing reports it. Only `String` and `OsString` are expected (upstream flips between exactly those two), so an arg that is present and readable as neither is a porting bug, not user input. Both helpers now `debug_assert!` on that case: loud under `cargo test`, and so in the weekly drift run's own test steps where it is actionable, while an embedder's release build degrades instead of aborting.
2 tasks done
chaliy
added a commit
that referenced
this pull request
Oct 20, 2026
… modules (#2759) Regenerated by `bashkit-coreutils-port` against uutils/coreutils@d2d96946b (was 8613dffab). Utilities: cat ls mktemp od readlink realpath shuf stat tac tee truncate. Vendored module: format. Two upstream argument-surface changes; the rest is the rev header bump. - `od`: the hidden FILENAME positional gains `value_parser(OsStringValueParser::new())`. No consumer change needed — #2754 landed `helpers::string_value` / `string_values`, which read od's arguments without naming the value type, so the switch is absorbed. - `tac`: `-s/--separator` gains `allow_hyphen_values(true)`, so a hyphen-leading separator parses as a value rather than a flag, matching upstream. This drift was produced by run 39234801977, which regenerated and pushed it but could not open a PR: the Actions job token is not permitted to create pull requests. The workflow's token is fixed separately in #2760. Verified on the pinned toolchain (1.95.0): `cargo build -p bashkit` clean, 48 od unit tests and 14 tac unit tests pass, and the bash spec suite passes — the same gate the drift workflow runs before proposing a diff.
2 tasks done
chaliy
added a commit
that referenced
this pull request
Oct 22, 2026
…ype (#2770) The weekly Coreutils Args Drift run has been red since upstream dropped `.value_parser(parse_range)` from `shuf`'s `input-range` arg and moved range parsing into its own `uumain`. The regenerated surface therefore stores a plain `String` where the pin stores a `RangeInclusive<u64>`. `shuf.rs` named only the pre-parsed type, so `get_one::<RangeInclusive<u64>>` mismatched on the regenerated surface. bashkit catches builtin panics, so the only symptom was `shuf -i 1-5` printing nothing: 3960/3989 spec cases passed and `shuf_input_range` failed. Run 39753862402 died there, at *Run cat/tac spec tests* -- after regeneration but before the patch upload, so no drift patch and no PR, which is why the drift stayed invisible. This is the documented failure mode from the `od` case (#2751/#2754): the drift PR enforces a generated-only diff and cannot repair its own consumers, so the consumer fix lands first and tolerates both surfaces. The new variant is that the two types are not the `String`/`OsString` pair `helpers::string_value` already covers -- upstream added and then dropped a value parser yielding a non-string type, moving the arg between "clap pre-parsed it" and "clap handed back raw text". `read_input_range` tries `try_get_one::<RangeInclusive<u64>>` first and falls back to `helpers::string_value` plus a local `parse_input_range`; an `Err` from the typed read means the other surface, not a bad value. The typed read is tried first so the string fallback never trips the `debug_assert` guarding a third, unhandled value type. Verified against both surfaces. Regenerating `shuf_args.rs` from upstream HEAD (eb7d426) shows the dropped value parser is the only semantic change in shuf's whole surface. On that regenerated surface the full spec suite, the shuf unit tests and the shuf resource tests pass; reverting to the pinned surface, all three pass again. Before the fix, the same regenerated surface failed `shuf_input_range` with empty stdout. Behaviour note, recorded in the knowledge: a malformed `-i` exits 2 with clap's rendering under the pinned surface, because clap rejects the value before shuf sees it. On the regenerated surface `parse_input_range` reports it instead and exits 1 with GNU's `shuf: invalid input range: '<range>'`. The pin bump moves this toward GNU, not away; no spec case pins the old shape.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
odnow reads its clap-parsed arguments without naming the value type upstream chose for them. Two new helpers,helpers::string_valuesandhelpers::string_value, tryOsStringthenStringthroughtry_get_many/try_get_one(which returnErrrather than panicking), andoduses them forFILENAME,-t/--format,--address-radix,--skip-bytes,--read-bytes,--widthand--endian.No user-visible change on the current pin. What changes is that
odkeeps working when upstream flips an arg's value parser.Why
The weekly Coreutils Args Drift run (39202465007) is red on
main. Upstream gaveod'sFILENAMEpositional anOsStringValueParser;od_options_from_matchesread it withget_many::<String>, and clap panics on a value-type mismatch.bashkit catches builtin panics, so
odjust produced nothing and the only symptom was one spec case losing one line. The run fails after regeneration, so no patch is uploaded and no drift PR opens — the job stays red until someone reads the log.The drift PR enforces a generated-only diff and so can never fix its own consumers (
knowledge/runtimes/coreutils-args-port.md§ The drift PR cannot fix its own consumers). Per that contract the consumer fix lands first, in its own PR, tolerating both value types so the surface is valid against the current pin and upstream HEAD — the only state in which the drift run can get past its build and test steps. The regenerated surfaces follow in the drift PR.Before / After
Reproduced locally by regenerating
od_args.rsagainst upstream HEAD (bbf2bfff2) and bumping the pin.Before —
cargo test -p bashkit --test integration -- spec_tests::bash_spec_tests:After — same regenerated surface, unchanged otherwise:
Both surfaces verified:
odunit tests8613dffab(String)bbf2bfff2(OsString)The guard test reproduces the CI panic when the fix is reverted:
Risk
to_string_lossytext conversion already used bycat,lsandtruncate, and an absent or unknown arg yieldsNone/ empty instead of panicking.od. Nine sibling builtins still nameOsStringdirectly and carry the mirror-image exposure (an upstream flip back toString); all only want text, so they are mechanically convertible. Recorded in the knowledge doc as "convert on touch" rather than widening this PR.Checklist