Re: [PATCH 5/5] show-ref: stop using PARSE_OPT_NO_INTERNAL_HELP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



René Scharfe <l.s.r@xxxxxx> writes:

> The flag PARSE_OPT_NO_INTERNAL_HELP is set to allow overriding the
> option -h, except when it's the only one given.
> This is the default behavior now,...

OK, so in the old world order, "-h" used to trigger the internal
help even before consulting parse_short_opt() to see if there is a
handler supplied by the caller, and NO_INTERNAL_HELP was invented as
a kludge to to disable this behaviour.  The existing two users
(dealt with 4/5 and 5/5) both used this mechanism to let their own
handler kick in, but they had to make "-h" without anything else on
the command line behave just like the internal one, while handling
"-h" with something else on the command line do a custom thing.

In the new world order, internal "-h" handler is called only after
seeing that parse_short_opt() decides there is no handler for "-h"
as a fallback.

	Side note.  Not really.  Among the three uses of
	intenal_help in parse_options_step(), the first one ("lone
	-h asks for help") is used before we ask parse_short_opt().

I wonder if we can/want to further tweak this in a follow-up
series.  If that is done, I think NO_INTERNAL_HELP can go away, as
its only effect would be to make us say "unknown option" when "-h"
alone was given from the command line for an options[] array that
does not have a handler for "-h".


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]