Re: [RFC PATCH] vreportf: ensure sensible ordering of normal and error output

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Nov 30 2021, Jeff King wrote:

> On Tue, Nov 30, 2021 at 09:05:54AM -0500, Eric Sunshine wrote:
>
>> >   - shouldn't status messages like this go to stderr anyway? I know some
>> >     people follow the "unless it is an error, it should not to go
>> >     stderr" philosophy. But I think in general our approach in Git is
>> >     more "if it is the main output of the program, it goes to stdout; if
>> >     it is chatter or progress for the user, it goes to stderr".
>> 
>> I considered this as well and agree that it would be a nicer localized
>> fix, but...
>> 
>> (1) I don't think the practice is documented anywhere, so people --
>> including me when I wrote builtin/worktree.c -- might not know about
>> it. Indeed, we don't seem to be entirely consistent about doing it
>> this way. Randomly picking submodule-helper.c, for instance, I see
>> status-like messages going to stdout:
>> 
>>     printf(_("Entering '%s'\n"), displaypath);
>>     printf(_("Synchronizing submodule url for '%s'\n"), ...);
>> 
>>     if (...)
>>         format = _("Cleared directory '%s'\n");
>>     else
>>         format = _("Could not remove submodule work tree '%s'\n");
>>     printf(format, displaypath);
>
> Yeah, we've definitely not been consistent here. There's no silver
> bullet for this aside from vigilance during review, but probably laying
> out guidelines could help.
>
> Here's a past discussion (that actually goes the other way: somebody
> complaining that stderr should be on stdout!) where I laid out my mental
> model:
>
>   https://lore.kernel.org/git/20110907215716.GJ13364@sigill.intra.peff.net/

...and a third way (which git doesn't conform to at all), which is that
std*err* is really what we should be using for errors only.

You shouldn't write anything that isn't an error there, or at least
that's what I've seen some software in the wild assume.

I've run into occasional problems with git over the years because it
writes to stderr routinely for non-errors, which flies in the face
assumptions made by various third-party software that assumes the
"that's for errors" model of the world.

E.g. look at the (very useful) "chronic" utility, which is in
"moreutils" in Debian. From its manpage:

   -e  Stderr triggering. Triggers output when stderr output length is non-zero.
       Without -e chronic needs non-zero return value to trigger output.

       In this mode, chronic's return value will be 2 if the command's
       return value is 0 but the command printed to stderr.

Right now I'm failing to recall what, but I remember dealing with that
behavior from git in some other contexts.