I'm so confused now...

Could you check this behaviour for other utils?

My guess is that the option parsing itself goes on to check for help on unrecognized options but that the loop around it doesn't? I think we could emulate it that way, but it'll be tricky.

Fascinating! I wrote a script to check how each command and option behaves, gathering 159 data points:

• Only two commands behave like this: du -B, du -d, du --time, as well the eight options bfhilnvw to nl.
• About a third of all options only check validity after going through the entire command like (see e.g. cut -fbanana versus cut -fbanana --help)
• The entire rest of all options (so far I tested) parses its argument immediately and raises an error immediately, as implemented in Make Options::apply fallible #113 (see e.g. df -Bkb and df -Bkb --help).

I'm happy to share the full results. Here's a screenshot of the partial results:

Script so you can run it yourself:

test_help.sh.but-for-github-i-renamed-it-to.txt

So it seems that GNU du and GNU nl are outliers.

Maybe we want to count that as a bug in GNU du and nl? @sylvestre, do you agree and if yes do you feel like reporting that bug?

I think I figured something out:

$ LC_ALL=C du --banana -B applepie README.md 
du: unrecognized option '--banana'
du: invalid -B argument 'applepie'
[$? = 1]

So it seems that GNU du tries to report all errors before returning, in contrast to basically all other utils:

$ LC_ALL=C df --banana -B applepie README.md 
df: unrecognized option '--banana'
Try 'df --help' for more information.
[$? = 1]

So I suggest we simply ignore this behavior of GNU du, in favor of consistency. Also, I really hope nobody relies on this weird behavior.