Skip to content

cut: match GNU's error for a bad --whitespace-delimited value - #14312

Closed
arbelonson-source wants to merge 1 commit into
uutils:mainfrom
arbelonson-source:fix/cut-whitespace-delimited-invalid-choice
Closed

cut: match GNU's error for a bad --whitespace-delimited value#14312
arbelonson-source wants to merge 1 commit into
uutils:mainfrom
arbelonson-source:fix/cut-whitespace-delimited-invalid-choice

Conversation

@arbelonson-source

Copy link
Copy Markdown
Contributor

What

--whitespace-delimited validates its value with a plain
ShortcutValueParser, so an unrecognized value produces clap's own
generic wording instead of GNU's:

$ echo "a b" | cut --whitespace-delimited=bogus -f1

# GNU
cut: invalid argument 'bogus' for '--whitespace-delimited'
Valid arguments are:
  - 'trimmed'
Try 'cut --help' for more information.

# uutils, before this PR
error: invalid value 'bogus' for '--whitespace-delimited[=<trimmed>]'

  [possible values: trimmed]

For more information, try '--help'.

Fix

Same fix already shipped across this series (#14293, #14303-#14311):
resolve the value against the option's own choice list by hand,
accepting any unambiguous abbreviation the way GNU does.

One thing specific to this option, since it has only a single
choice: the empty string (--whitespace-delimited=) is a prefix of
every choice, same as it is for the other options in this series --
but here there's only one choice for it to be a prefix of, so it
names it unambiguously rather than being ambiguous. GNU accepts it and
treats it exactly like =trimmed:

$ printf ' a  b \n' | cut --whitespace-delimited= -f1,2
a	b

An existing test (test_whitespace_delimited_long_and_trimmed, which
already looped over ["trimmed", "tri", ""]) caught my first attempt
at this fix immediately -- I'd carried over the same
not-empty-unless-otherwise-resolvable guard from the other options in
this series, which is correct where multiple choices make an empty
value genuinely ambiguous, but wrong here where there's nothing to be
ambiguous with.

Testing

  • cargo test -p uu_cut / full tests/by-util/test_cut.rs suite: 83 passed, 0 failed.
  • Strengthened the existing invalid-value test to assert the exact GNU wording.
  • Manually diffed every --whitespace-delimited value (valid, abbreviated, empty, invalid) against GNU cut 9.11 under LC_ALL=C, including the trimming behavior (not just the error path) for the empty-value case.
  • cargo clippy -p uu_cut --all-targets -- -D warnings and cargo fmt --check: clean.

This PR was written with AI assistance (Claude Opus 5, via Claude Code). I've tested the changes but please review the code carefully.

--whitespace-delimited validated its value with a plain
ShortcutValueParser, so an unrecognized value produced clap's own
generic wording instead of GNU's ('invalid argument ... for
--whitespace-delimited / Valid arguments are: / - 'trimmed' / ...').

Resolve the value against the option's own (single-choice) list by
hand, accepting any unambiguous abbreviation the way GNU does --
including the empty string, e.g. --whitespace-delimited=: with only
one choice, the empty string (a prefix of every choice, same as the
other options fixed in this series) names it unambiguously, so it
resolves to 'trimmed' rather than erroring. An existing test
(test_whitespace_delimited_long_and_trimmed) already asserted this
exact behavior for '' and caught my first attempt, which mirrored the
other fixes' guard against a *genuinely* ambiguous empty value and
wrongly rejected it here where there is nothing to be ambiguous with.

AI-assisted-by: Claude Opus 5, via Claude Code
@oech3

oech3 commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

No meaning change. Please stop aligning error message with GNU by removing clap.

@github-actions

Copy link
Copy Markdown

GNU testsuite comparison:

Skipping an intermittent issue tests/cut/bounded-memory (passes in this run but fails in the 'main' branch)
Skip an intermittent issue tests/pr/bounded-memory (was skipped on 'main', now failing)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants