fix(builtins): read od's generated args under either clap value type

[chaliy]

What changed

od now reads its clap-parsed arguments without naming the value type upstream chose for them. Two new helpers, helpers::string_values and helpers::string_value, try OsString then String through try_get_many / try_get_one (which return Err rather than panicking), and od uses them for FILENAME, -t/--format, --address-radix, --skip-bytes, --read-bytes, --width and --endian.

No user-visible change on the current pin. What changes is that od keeps working when upstream flips an arg's value parser.

Why

The weekly Coreutils Args Drift run (39202465007) is red on main. Upstream gave od's FILENAME positional an OsStringValueParser; od_options_from_matches read it with get_many::<String>, and clap panics on a value-type mismatch.

bashkit catches builtin panics, so od just 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.rs against upstream HEAD (bbf2bfff2) and bumping the pin.

Before — cargo test -p bashkit --test integration -- spec_tests::bash_spec_tests:

thread 'spec_tests::bash_spec_tests' panicked at crates/bashkit/src/builtins/hextools.rs:306:10:
Mismatch between definition and access of `FILENAME`. Could not downcast to
alloc::string::String, need to downcast to std::ffi::os_str::OsString
Total: 3989 | Passed: 3960 | Failed: 1 | Skipped: 28

[process-env-builtins.test] dd_zero_device_and_seek
  Expected stdout: "3072\n  \0   X   Y  \0  \0 ...\n32\n"
  Got stdout:      "3072\n32\n"

After — same regenerated surface, unchanged otherwise:

test spec_tests::bash_spec_tests ... ok
test result: ok. 1 passed; 0 failed

Both surfaces verified:

Surface	Spec suite	od unit tests
pinned 8613dffab (String)	3989 pass	48 pass
upstream HEAD bbf2bfff2 (OsString)	3989 pass	48 pass

The guard test reproduces the CI panic when the fix is reverted:

test builtins::hextools::tests::od_options_read_either_value_parser ... FAILED
panicked at crates/bashkit/src/builtins/hextools.rs:304:10:
Mismatch between definition and access of `FILENAME`.

Risk

• Low.
• The helpers are strictly more permissive than the reads they replace: same to_string_lossy text conversion already used by cat, ls and truncate, and an absent or unknown arg yields None / empty instead of panicking.
• Scoped to od. Nine sibling builtins still name OsString directly and carry the mirror-image exposure (an upstream flip back to String); all only want text, so they are mechanically convertible. Recorded in the knowledge doc as "convert on touch" rather than widening this PR.

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	2123d5f	Commit Preview URL Branch Preview URL	Oct 19 2026, 09:48 AM