Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

date: iso-8601 argument format discrepancy #6387

Open
my4ng opened this issue May 9, 2024 · 2 comments
Open

date: iso-8601 argument format discrepancy #6387

my4ng opened this issue May 9, 2024 · 2 comments
Labels

Comments

@my4ng
Copy link

my4ng commented May 9, 2024

The coreutils version currently accepts more argument option-value formats than that of the GNU version:

GNU:
-I[FMT], --iso-8601[=FMT] output date/time in ISO 8601 format...
coreutils:
-I, --iso-8601 [<FMT>] output date/time in ISO 8601 format...

This means the following arguments are accepted by coreutils but not GNU:

  • date -I=seconds
  • date -I seconds
  • date --iso-8601 seconds

GNU will treat =seconds as the value in the first one, and treat seconds as the positional argument [+FORMAT] in the next two.

coreutils will also reject some that are accepted by GNU since it will take the positional argument as the argument value, e.g. date -I 05091009:

error: invalid value '05091009' for '--iso-8601 [<FMT>]'
  [possible values: date, hours, minutes, seconds, ns]

This cannot be simply fixed by setting require_equals for the clap argument, since it would also preclude the correct syntax -Iseconds. There probably are more examples of this discrepancy in coreutils (please comment below).

This is a known limitation in clap, and I have commented in this clap issue and made a fix PR.

@BenWiederhake
Copy link
Collaborator

The first part seems to be no big problem: After all, having an extension to GNU is fine, as long as we remain drop-in compatible.

The second part seems to be a bigger problem. Also see #4254 because it seems more and more that clap is an awesome project, but simply solves a different problem than we have. Here's a demonstration that uutils-args will be able to handle this particular case correctly: https://github.com/uutils/uutils-args/pull/113/files#diff-8da4a3571369459ddecc9e114ae27fef1bd0f3c8ae3e81334ef463b425981ab3R137-R165

@my4ng
Copy link
Author

my4ng commented May 10, 2024

Indeed. They are very hesitant to introduce breaking changes because how many things depend on it.

Which particular part in the diff are you referring to?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants