[chaliy]

What changed

shuf now reads its -i LO-HI argument without naming the value type upstream chose for it. read_input_range tries the pre-parsed RangeInclusive<u64> first and falls back to the raw string plus a local parse_input_range; an Err from the typed read means the other surface, not a bad value.

This unblocks the weekly Coreutils Args Drift run, which is the last red workflow on main.

Why

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 after regeneration. 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. That is why the drift has stayed invisible rather than surfacing as a reviewable diff.

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". knowledge/runtimes/coreutils-args-port.md records that generalization.

Before / After

Regenerating shuf_args.rs from upstream HEAD (eb7d426) shows the dropped value parser is the only semantic change in shuf's whole surface — every other arg (head-count u64, output path_buf, file-or-args os_string, …) is byte-identical:

-fn parse_range(input_range: &str) -> Result<RangeInclusive<u64>, String> { ... }
                 Arg::new(options::INPUT_RANGE)
-                .value_parser(parse_range)

Before — regenerated surface, CI run 39753862402:

[shuf.test] shuf_input_range
  Expected stdout: "1\n2\n3\n4\n5\n"
  Got stdout:      ""

=== Bash Spec Tests ===
Total: 3989 | Passed: 3960 | Failed: 1 | Skipped: 28

After — same regenerated surface, locally:

$ cargo test -p bashkit --test integration -- spec_tests::bash_spec_tests
test result: ok. 1 passed; 0 failed

$ cargo test -p bashkit --test integration -- shuf
test shuf_resource_tests::shuf_range_head_count_does_not_materialize_full_range ... ok
test shuf_resource_tests::shuf_repeat_head_count_is_checked_before_output_allocation ... ok
test result: ok. 2 passed; 0 failed

Reverting to the pinned surface, all of the above pass again — the point of the change is that both hold at once.

Behaviour note. 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 therefore moves this diagnostic toward GNU, not away from it; no spec case pins the old shape.

Risk

• Low
• The typed read is tried first, so the pinned surface takes exactly the path it takes today; the fallback is unreachable until the pin moves.
• Ordering matters for one subtle reason: the string fallback carries a debug_assert that fires when an arg is present but readable as neither String nor OsString. Reading the typed value first keeps that guard pointed at genuinely unhandled types instead of tripping on the pinned RangeInclusive. absent_input_range_reads_none_under_both_value_types covers the no--i case on both shapes.
• parse_input_range duplicates upstream's body-code parser, which is not vendored. It can drift independently; the unit tests pin GNU's semantics, including the LO == HI + 1 empty-range spelling.

Checklist

• Tests added or updated
• Backward compatibility considered

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	590d35a	Commit Preview URL Branch Preview URL	Oct 22 2026, 09:49 AM