git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Dec 1, 2021, 05:32 UTC
Message-ID
<20211201053214.2902-1-sunshine@sunshineco.com>

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.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
 Documentation/CodingGuidelines | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 711cb9171e..44dd178dc9 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -499,6 +499,32 @@ For Python scripts:
  - Where required libraries do not restrict us to Python 2, we try to
    also be compatible with Python 3.1 and later.
 
+
+Program Output
+
+ We make a distinction between a command's primary output and output
+ which is merely chatty feedback (for instance, status messages,
+ running transcript, or progress display), as well as error messages.
+ Roughly speaking, a command's primary output is that which one might
+ want to capture to a file or send down a pipe; its chatty output
+ should not interfere with those use-cases.
+
+ As such, primary output should be sent to the standard output stream
+ (stdout), and chatty output should be sent to the standard error
+ stream (stderr). Examples of commands which produce primary output
+ include `git log`, `git show`, and `git branch --list` which generate
+ output on the stdout stream.
+
+ Not all commands have primary output; this is often true of commands
+ whose main function is to perform an action. Some action commands are
+ silent, whereas others are chatty. An example of a chatty action
+ commands is `git clone` with its "Cloning into '<path>'..." and
+ "Checking connectivity..." status messages which it sends to the
+ stderr stream.
+
+ Error messages are always sent to the stderr stream.
+
+
 Error Messages
 
  - Do not end error messages with a full stop.
-- 
2.34.1.75.gabe6bb3905
Next: Fabian Stelzer
Message 1 of 12 in “CodingGuidelines: document which output goes to stdout vs. stderr”
  1. CodingGuidelines: document which output goes to stdout vs. stderrEric Sunshine, Dec 1, 2021
  2. Fabian StelzerDec 1, 2021
  3. Eric SunshineDec 1, 2021
  4. Fabian StelzerDec 1, 2021
  5. Junio C HamanoDec 1, 2021
  6. Eric SunshineDec 1, 2021
  7. Jeff KingDec 1, 2021
  8. Eric SunshineDec 1, 2021
  9. Philip OakleyDec 1, 2021
  10. Eric SunshineDec 1, 2021
  11. CodingGuidelines: document which output goes to stdout vs. stderrEric Sunshine, Dec 2, 2021
  12. Jeff KingDec 2, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.