Fix: coreutils now allows options with incomplete names by GunterSchmidt · Pull Request #11348 · uutils/coreutils

GunterSchmidt · 2026-03-16T15:32:51Z

Addresses issue #10269.

Changes

Allow options with --l, --li or similar for --list
Prioritize options: -V --list --help will return help -V --list will return version
Added tests
Selected option now is returned as Enum for better code readability.
No functional changes

coreutils arguments

first arg needs to be the binary/executable. \ This is usually coreutils, but can be the util name itself, e.g. 'ls'. \ The util name will be checked against the list of enabled utils, where
- the name exactly matches the name of an applet/util or
- the name matches <UTIL_NAME> pattern, e.g. 'my_own_directory_service_ls' as long as the last letters match the utility.
coreutils arg: --list, --version, -V, --help, -h (or shortened long versions): \ Output information about coreutils itself. \ Multiple of these arguments, output limited to one, with help > version > list.
util name and any number of arguments: \ Will get passed on to the selected utility. \ Error if util name is not recognized.
--help or -h and a following util name: \ Output help for that specific utility. \ So 'coreutils sum --help' is the same as 'coreutils --help sum'.

Addresses issue uutils#10269. * Allow options with --l, --li or similar for --list * Prioritize options: -V --list --help will return help -V --list will return version * Added tests * Selected option now is returned as Enum for better code readability. * No functional changes * first arg needs to be the binary/executable. \ This is usually coreutils, but can be the util name itself, e.g. 'ls'. \ The util name will be checked against the list of enabled utils, where * the name exactly matches the name of an applet/util or * the name matches <PREFIX><UTIL_NAME> pattern, e.g. 'my_own_directory_service_ls' as long as the last letters match the utility. * coreutils arg: --list, --version, -V, --help, -h (or shortened long versions): \ Output information about coreutils itself. \ Multiple of these arguments, output limited to one, with help > version > list. * util name and any number of arguments: \ Will get passed on to the selected utility. \ Error if util name is not recognized. * --help or -h and a following util name: \ Output help for that specific utility. \ So 'coreutils sum --help' is the same as 'coreutils --help sum'.

oech3 · 2026-03-16T15:43:26Z

GNU does not have -V.

oech3 · 2026-03-16T15:44:57Z

src/bin/coreutils.rs

-    let util_name = if let Some(&util) = matched_util {
-        Some(OsString::from(util))
-    } else if is_coreutils || binary_as_util.ends_with("box") {
-        // todo: Remove support of "*box" from binary


This is not too easy. We have this for BusyBox tests.

Ah, interesting. I just saw the to do and removed it. Will implement it again.
-V is not GNU, but uutils standard, see extensions.md.

opened mirror/busybox#117

Actually, I'm considering to remove -h,-V extensions to avoid confliction in the future. (We already have some probrematic conflictions...)

github-actions · 2026-03-16T15:45:36Z

GNU testsuite comparison:

Congrats! The gnu test tests/expand/bounded-memory is now passing!

oech3 · 2026-03-16T16:17:17Z

Would you wait merging #10889 ? I'm worrying about regression.

Fixed some clippy warnings.

GunterSchmidt · 2026-03-16T16:52:56Z

Sure, I do not mind merging #10889 first at all. This is a core module, so safety first.

I am using Enums as this makes the prioritization logic a bit simpler and increases readability. In my experience, Enums make code more maintainable, but that may be a personal preference.
Since this is only used in cases where not a util is started, I do not see any harm.

Diff is large, indeed. This is because I moved most error situations to the top and all code regarding coreutil options to the bottom so it is not scattered around. I also removed some nesting levels, making it easier to follow the code structure.

oech3 · 2026-03-16T16:55:22Z

able to split PR? overkill?

github-actions · 2026-03-16T16:56:29Z

GNU testsuite comparison:

Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/csplit/csplit-heap is now being skipped but was previously passing.
Note: The gnu test tests/tail/tail-n0f is now being skipped but was previously passing.
Congrats! The gnu test tests/expand/bounded-memory is now passing!

The previous commit had some additional code restructuring which made diff checking difficult. Here the same functionality is implemented, but now it is clearer that only the None path of "match utils.get" has changed. This only affects coreutils own option parsing.

GunterSchmidt · 2026-03-16T17:53:54Z

I see your point. This version now has less changes to the original. Only the None-case has changed when no util was found to redirect to.

oech3 · 2026-03-16T17:59:55Z

I stil think enum is overkill...

GunterSchmidt · 2026-03-16T18:24:43Z

Well, I have to disagree with that, as Enums work faster and are more secure, but that is opinionated. I am flexible on this, so I removed the Enum.

oech3 · 2026-03-16T19:06:10Z

It might better to just switch to clap which supports incomplete flags and localization (though I don't like clap's overhead...)

GunterSchmidt · 2026-03-16T21:48:03Z

Why, you would be adding a lot of overhead for a selection of 3 options. The first commit I did was the cleanest, safest and most readable code.
So, maybe you can elaborate on your feelings:
a) Why is a Diff for one single function to big?
b) What are the reasons that speak against an Enum? How is Overkill affecting the code?
c) What would be the technical benefit of introducing Clap?

Enums are technically superior: Easier to maintain, safer to work with and more performant.

oech3 · 2026-03-17T04:40:44Z

I'm not hoping to reinvent the wheel. I might try to use clap at cold code-path of coreutils for cleaner code base.

github-actions · 2026-03-17T07:37:34Z

GNU testsuite comparison:

Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/expand/bounded-memory is now passing!

GunterSchmidt · 2026-03-17T09:23:38Z

And you think that implementing clap is less complex? That is like using a Content Management System to write a single note.

oech3 · 2026-03-17T09:30:26Z

Ofcause. We are already relying on clap's incomplete long arg support at most utils.

oech3 · 2026-03-17T12:43:09Z

--help or -h and a following util name: \ Output help for that specific utility. \ So 'coreutils sum --help' is the same as 'coreutils --help sum'.

How about coreutils sort -h where -h is "not" help?

oech3 · 2026-03-17T13:47:34Z

GNU's coreutils --help string is same with coreutils --help.

GunterSchmidt · 2026-03-17T14:42:26Z

About your question: "How about coreutils sort -h where -h is "not" help?"

This is how it works:

When calling "coreutils sort -h" coreutils calls uumain of sort, so "sort -h" and sort will take the -h with its specific meaning. It is just stripping "coreutils" binary from the args and passing the rest on.
When calling "coreutils -h sort" coreutils will call sort with arg --help, so "sort --help", which is exactly the same as "coreutils sort --help"

I do not know why this was build into coreutils, but I did not want to change it.

oech3 · 2026-03-17T14:46:18Z

OK. I'll drop coreutils --help string in any cases.

oech3 reviewed Mar 16, 2026

View reviewed changes

This comment was marked as outdated.

Sign in to view

Fix: added end_with("box") again for busy_box tests

726911c

Fixed some clippy warnings.

replaced SelectedOption Enum with Strings

08b497c

Update comment

e35265b

Reverting to Enums

7c1b167

Enums are technically superior: Easier to maintain, safer to work with and more performant.

Uh oh!

Conversation

GunterSchmidt commented Mar 16, 2026

Changes

coreutils arguments

Uh oh!

oech3 commented Mar 16, 2026

Uh oh!

oech3 Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

GunterSchmidt Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

oech3 Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

oech3 Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Mar 16, 2026

Uh oh!

This comment was marked as outdated.

oech3 commented Mar 16, 2026

Uh oh!

GunterSchmidt commented Mar 16, 2026

Uh oh!

oech3 commented Mar 16, 2026

Uh oh!

github-actions bot commented Mar 16, 2026

Uh oh!

GunterSchmidt commented Mar 16, 2026

Uh oh!

oech3 commented Mar 16, 2026

Uh oh!

GunterSchmidt commented Mar 16, 2026

Uh oh!

oech3 commented Mar 16, 2026 via email

Uh oh!

GunterSchmidt commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oech3 commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 17, 2026

Uh oh!

GunterSchmidt commented Mar 17, 2026

Uh oh!

oech3 commented Mar 17, 2026

Uh oh!

oech3 commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oech3 commented Mar 17, 2026

Uh oh!

GunterSchmidt commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oech3 commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

GunterSchmidt commented Mar 16, 2026 •

edited

Loading

oech3 commented Mar 17, 2026 •

edited

Loading

oech3 commented Mar 17, 2026 •

edited

Loading

GunterSchmidt commented Mar 17, 2026 •

edited

Loading