On Wed, Jan 15, 2025 at 01:16:50PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Yeah, I agree it is funny to have a "maybe noop, maybe exit" function. > > Perhaps a different name would help? I'd expect show_usage_help() to > > always do what the name says. Maybe check_help_option() or something? > > maybe_show_usage_help()? Heh, I almost suggested that one, too, but worried it was too clunky. But maybe since we both thought of it... > > I think parse-options will exit(129) in this case, and that's what t0012 > > insists upon. > > Yeah, but the test can be adjusted to updated reality if needed. > > In this case, the command is doing what the end-user asked it to do, > and if we were writing the system from scratch, 0 would certainly be > the right exit status in this case. If hit usage_with_options() > because the command line option supplied by the user was nonsense, > we should exit with non-zero, but I am not sure if exit(129) is a > good idea here. I certainly see an argument for exit(0), but whatever we do should be consistent with how parse-options handles it (since whether we use this or leave it to parse-options is purely an implementation detail that the user should not need to be aware of). And it uses code 129, even for "-h". I don't see any explicit rationale for that in the history; I think it goes back to the beginning of parse-options. It happens via the PARSE_OPT_HELP flag, but curiously we also trigger that for ambiguous options (which should exit with error). That might be a bug-in-waiting if we start handling PARSE_OPT_HELP differently. -Peff
