为什么 "git submodule add ..." 写入 stderr 而不是 stdout?
Why does "git submodule add ..." write to stderr rather than stdout?
留言
Cloning into 'sub-mod'...
done.
在 git submodule add...
命令写入 stderr 之后。我希望将消息写入 stdout,因为我认为这并不表示命令出了问题。
我可以使用以下命令序列重现此内容:
rm -rf /tmp/repo /tmp/module
mkdir /tmp/repo /tmp/module
cd /tmp/module
git init > /dev/null
echo "foo" > foo;
git add foo > /dev/null
git commit . -m "+ foo" > /dev/null
cd /tmp/repo
git init > /dev/null
git submodule add /tmp/module/ sub-mod 1> /dev/null
如果我将最后一个命令中的重定向更改为 ... 2> /dev/null
,则不会打印任何内容。
这不限于子模块,如noted here:
The registration of the submodule will be reported to stderr, as that is
consistent with the rest of progress reporting within Git.
This helps us in a later patch when we want to reuse the
init_submodule
function in update_clone
whose stdout will be piped
to shell which reads parameters off stdout in a very specific way.
你也可以在this recent patch看到它:
Reroute the output of stdout to stderr as it is just informative
messages, not to be consumed by machines.
We want to init submodules from the helper for submodule update
in a later patch and the stdout output of said helper is consumed
by the parts of submodule update
which are still written in shell.
So we have to be careful which messages are on stdout.
在 Git 2.35(2022 年第一季度)中,编码指南文档已更新,以阐明我们系统中的标准错误。
参见 commit e258eb4 (02 Dec 2021) by Eric Sunshine (sunshineco
)。
(由 Junio C Hamano -- gitster
-- in commit 212962d 合并,2021 年 12 月 15 日)
CodingGuidelines
: document which output goes to stdout vs. stderr
Signed-off-by: Eric Sunshine
Acked-by: Jeff King
It has long been practice on 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 practice is not necessarily universal; another common practice is to send only error messages to stderr, and all other messages to stdout.
Therefore, help newcomers out by documenting how stdout and stderr are used on this project.
CodingGuidelines
现在包含在其 man page 中:
Program Output
We make a distinction between a Git 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 Git 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 these 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 Git 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
''..." and "Checking connectivity..." status messages which it
sends to the stderr stream.
Error messages from Git commands should always be sent to the stderr
stream.
留言
Cloning into 'sub-mod'...
done.
在 git submodule add...
命令写入 stderr 之后。我希望将消息写入 stdout,因为我认为这并不表示命令出了问题。
我可以使用以下命令序列重现此内容:
rm -rf /tmp/repo /tmp/module
mkdir /tmp/repo /tmp/module
cd /tmp/module
git init > /dev/null
echo "foo" > foo;
git add foo > /dev/null
git commit . -m "+ foo" > /dev/null
cd /tmp/repo
git init > /dev/null
git submodule add /tmp/module/ sub-mod 1> /dev/null
如果我将最后一个命令中的重定向更改为 ... 2> /dev/null
,则不会打印任何内容。
这不限于子模块,如noted here:
The registration of the submodule will be reported to stderr, as that is consistent with the rest of progress reporting within Git.
This helps us in a later patch when we want to reuse the
init_submodule
function inupdate_clone
whose stdout will be piped to shell which reads parameters off stdout in a very specific way.
你也可以在this recent patch看到它:
Reroute the output of stdout to stderr as it is just informative messages, not to be consumed by machines.
We want to init submodules from the helper for
submodule update
in a later patch and the stdout output of said helper is consumed by the parts ofsubmodule update
which are still written in shell.
So we have to be careful which messages are on stdout.
在 Git 2.35(2022 年第一季度)中,编码指南文档已更新,以阐明我们系统中的标准错误。
参见 commit e258eb4 (02 Dec 2021) by Eric Sunshine (sunshineco
)。
(由 Junio C Hamano -- gitster
-- in commit 212962d 合并,2021 年 12 月 15 日)
CodingGuidelines
: document which output goes to stdout vs. stderrSigned-off-by: Eric Sunshine
Acked-by: Jeff King
It has long been practice on 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 practice is not necessarily universal; another common practice is to send only error messages to stderr, and all other messages to stdout.
Therefore, help newcomers out by documenting how stdout and stderr are used on this project.
CodingGuidelines
现在包含在其 man page 中:
Program Output
We make a distinction between a Git 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 Git 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 these 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
, andgit branch --list
which generate output on the stdout stream.Not all Git 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 ''..." and "Checking connectivity..." status messages which it sends to the stderr stream.Error messages from Git commands should always be sent to the stderr stream.