git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 4/6] usage: add show_usage_and_exit_if_asked()
Date: Thu, 16 Jan 2025 09:22:54 -0800	[thread overview]
Message-ID: <xmqqbjw6u101.fsf@gitster.g> (raw)
In-Reply-To: <20250116103620.GB773990@coredump.intra.peff.net> (Jeff King's message of "Thu, 16 Jan 2025 05:36:20 -0500")

Jeff King <peff@peff.net> writes:

>> 	show_usage_and_exit_if_asked(argc, argv, usage);
>> 
>> to help correct these code paths.
>
> I found the name hard to distinguish from the earlier helper,

As we all know that usage_with_options() and usage() exits,

    show_usage_with_options_if_asked()
    show_usage_if_asked()

may be good enough, I wonder?  "show" -> "help" may give us better
names.

> I think the "and_exit" could probably be implied, since showing the
> usage is always a final thing (just like in usage() and
> usage_with_options()). So:
>
>   show_usage_if_asked();
>   show_usage_with_options_if_asked();

Ah, We came to the same conclusion.  The only thing we haven't made
it obvious is that "show" implies the output goes to the standard
output stream, while without "show", the output goes to the standard
error stream.  I wonder if these help better:

    show_help_if_asked();
    show_help_with_options_if_asked()

"show help" explains the output goes to where the "help" message
would go ;-)

But probably "if-asked" is clear enough indication that the output
is made in response to an explicit end-user request, so let's take
the show_(usage|usage_with_options)_if_asked as the final names.

>> -static void vreportf(const char *prefix, const char *err, va_list params)
>> +static void vfdreportf(int fd, const char *prefix, const char *err, va_list params)
>>  {
>>  	char msg[4096];
>>  	char *p, *pend = msg + sizeof(msg);
>> @@ -32,8 +32,14 @@ static void vreportf(const char *prefix, const char *err, va_list params)
>>  	}
>>  
>>  	*(p++) = '\n'; /* we no longer need a NUL */
>> -	fflush(stderr);
>> -	write_in_full(2, msg, p - msg);
>> +	if (fd == 2)
>> +		fflush(stderr);
>> +	write_in_full(fd, msg, p - msg);
>> +}
>
> Gross. :) I think the existing code is conceptually:
>
>   write_in_full(fileno(stderr), msg, p - msg);
>
> In which case vfreportf() could just take a FILE*, flush it and then
> write.

Sure, but these "stderr" are real error reporting that need to stay
to be stderr, and flush needs to be done only when our true payload
goes to fd#2 and I do not think these fflush() are about stdio calls
made by the caller _before_ it called this function.  It may become
a bit tricky to read the resulting code if we pass "FILE *".

  parent reply	other threads:[~2025-01-16 17:22 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16  1:25 [PATCH v3 0/6] Send help text from "git cmd -h" to stdout Junio C Hamano
2025-01-16  1:25 ` [PATCH v3 1/6] parse-options: add show_usage_help_and_exit_if_asked() Junio C Hamano
2025-01-16  1:25 ` [PATCH v3 2/6] t0012: optionally check that "-h" output goes to stdout Junio C Hamano
2025-01-16  1:25 ` [PATCH v3 3/6] builtins: send usage_with_options() help text to standard output Junio C Hamano
2025-01-16  1:25 ` [PATCH v3 4/6] usage: add show_usage_and_exit_if_asked() Junio C Hamano
2025-01-16 10:36   ` Jeff King
2025-01-16 10:44     ` Jeff King
2025-01-16 17:22     ` Junio C Hamano [this message]
2025-01-16 21:54       ` Jeff King
2025-01-16 22:26         ` Junio C Hamano
2025-01-16  1:25 ` [PATCH v3 5/6] oddballs: send usage() help text to standard output Junio C Hamano
2025-01-16 10:42   ` Jeff King
2025-01-16 17:24     ` Junio C Hamano
2025-01-16  1:25 ` [PATCH v3 6/6] builtin: " Junio C Hamano
2025-01-16 17:30   ` Junio C Hamano
2025-01-16 20:37     ` Junio C Hamano
2025-01-16 10:46 ` [PATCH v3 0/6] Send help text from "git cmd -h" to stdout Jeff King
2025-01-16 17:28   ` Junio C Hamano
2025-01-16 21:35 ` [PATCH v4 " Junio C Hamano
2025-01-16 21:35   ` [PATCH v4 1/6] t0012: optionally check that "-h" output goes " Junio C Hamano
2025-01-16 21:35   ` [PATCH v4 2/6] parse-options: add show_usage_with_options_if_asked() Junio C Hamano
2025-01-16 21:35   ` [PATCH v4 3/6] usage: add show_usage_if_asked() Junio C Hamano
2025-01-16 23:00     ` Junio C Hamano
2025-01-17 11:41       ` Jeff King
2025-01-16 21:35   ` [PATCH v4 4/6] builtins: send usage_with_options() help text to standard output Junio C Hamano
2025-01-16 21:35   ` [PATCH v4 5/6] oddballs: send usage() " Junio C Hamano
2025-01-16 21:35   ` [PATCH v4 6/6] builtin: " Junio C Hamano
2025-01-17 11:42     ` Jeff King
2025-01-17 19:46       ` Junio C Hamano
2025-01-17 21:31   ` [PATCH v5 0/6] Send help text from "git cmd -h" to stdout Junio C Hamano
2025-01-17 21:31     ` [PATCH v5 1/6] t0012: optionally check that "-h" output goes " Junio C Hamano
2025-01-17 21:31     ` [PATCH v5 2/6] parse-options: add show_usage_with_options_if_asked() Junio C Hamano
2025-01-17 21:31     ` [PATCH v5 3/6] usage: add show_usage_if_asked() Junio C Hamano
2025-01-17 21:31     ` [PATCH v5 4/6] builtins: send usage_with_options() help text to standard output Junio C Hamano
2025-01-17 21:31     ` [PATCH v5 5/6] oddballs: send usage() " Junio C Hamano
2025-01-17 21:31     ` [PATCH v5 6/6] builtin: " Junio C Hamano
2025-01-18 11:42     ` [PATCH v5 0/6] Send help text from "git cmd -h" to stdout Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqbjw6u101.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).