Re: [PATCH] CodingGuidelines: document which output goes to stdout vs. stderr

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

 



On Wed, Dec 01, 2021 at 12:32:14AM -0500, Eric Sunshine wrote:

> It has long been practice in this project for a command to emit its
> primary output to stdout so that it can be captured to a file or sent
> down a pipe, and to emit "chatty" messages (such as those reporting
> progress) to stderr so that they don't interfere with the primary
> output. However, this idiomatic Unix practice is not necessarily
> universally understood and may be at odds with other schools of thought,
> such as the somewhat common one that only error messages should go to
> stderr, and all other messages to stdout. Let's help newcomers by
> documenting how stdout and stderr are used on this project.

I agree with everything you wrote here and below, which I think captures
what we want to communicate to folks adding new messages or commands.

I am not quite sure _everyone_ would agree with "this idiomatic Unix
practice" above. It does seem to be a matter of taste (it is just that
what you wrote very much agrees with my taste :) ). And "idiomatic Unix
practice" is probably not to be chatty at all, but I think that has been
changing over the years.

So I'm not sure if your commit message is being nicely assertive about
its taste, or is being uncharitable to people who may have different
tastes (but again, IMHO we should pick a direction and this seems like
the best one to me). :)

-Peff



[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]

  Powered by Linux