I am rather confused with the purpose of these three files. If my understanding is correct, stdin is the file in which a program writes into its requests to run a task in the process. stdout is the file into which the kernel writes its output and the process requesting it accesses the information from and stderr is the file into which all the exceptions are entered. On opening these files to check whether these actually do occur, I found nothing seem to suggest so!
我对这三个文件的目的很困惑。如果我的理解是正确的，那么stdin就是程序在其请求中写入以在进程中运行任务的文件。stdout是内核写入输出的文件，请求它访问来自该文件的信息的进程，而stderr是输入所有异常的文件。当我打开这些文件检查这些文件是否真的发生时，我发现似乎没有什么建议!
What I would want to know is what exactly is the purpose of these file, absolutely dumbed down answer with very little tech jargon!
我想知道的是，这些文件的目的到底是什么，用非常少的技术术语来彻底地简化答案!
9 个解决方案
#1
150
Standard input - this is the file handle that your process reads to get information from you.
标准输入——这是进程读取的文件句柄，用于从您那里获取信息。
Standard output - your process writes normal information to this file handle.
标准输出—您的进程将正常信息写入此文件句柄。
Standard error - your process writes error information to this file handle.
标准错误——您的进程将错误信息写入这个文件句柄。
That's about as dumbed-down as I can make it :-)
那是我能做的最愚蠢的事:
Of course, that's mostly by convention. There's nothing stopping you from writing your error information to standard output if you wish. You can even close the three file handles totally and open your own files for I/O.
当然，这主要是根据惯例。如果您愿意，没有什么可以阻止您将错误信息写入标准输出。您甚至可以完全关闭三个文件句柄，并为I/O打开自己的文件。
When your process starts, it should already have these handles open and it can just read from and/or write to them.
当您的进程开始时，它应该已经打开了这些句柄，并且它可以直接读取和/或写入这些句柄。
By default, they're probably connected to your terminal device (e.g., /dev/tty) but shells will allow you to set up connections between these handles and specific files and/or devices (or even pipelines to other processes) before your process starts (some of the manipulations possible are rather clever).
默认情况下，它们可能连接到您的终端设备(例如/dev/tty)，但是shell将允许您在进程开始之前在这些句柄和特定的文件和/或设备(甚至管道到其他进程)之间建立连接(一些可能的操作是相当聪明的)。
An example being:
一个例子:
my_prog <inputfile 2>errorfile | grep XYZ
which will:
将:
- create a process for
my_prog. - 为my_prog创建一个进程。
- open
inputfileas your standard input (file handle 0). - 打开inputfile作为标准输入(文件句柄为0)。
- open
errorfileas your standard error (file handle 2). - 打开errorfile作为标准错误(文件句柄2)。
- create another process for
grep. - 为grep创建另一个进程。
- attach the standard output of
my_progto the standard input ofgrep. - 将my_prog的标准输出附加到grep的标准输入。
Re your comment:
是你的评论:
When I open these files in /dev folder, how come I never get to see the output of a process running?
当我在/dev文件夹中打开这些文件时，为什么我从来没有看到一个进程的输出?
It's because they're not normal files. While UNIX presents everything as a file in a file system somewhere, that doesn't make it so at the lowest levels. Most files in the /dev hierarchy are either character or block devices, effectively a device driver. They don't have a size but they do have a major and minor device number.
因为它们不是普通的文件。虽然UNIX将所有内容都表示为某个文件系统中的一个文件，但这并不意味着它是最低级别的文件。/dev层次结构中的大多数文件都是字符或块设备，实际上是设备驱动程序。它们没有大小，但是有一个主要的和次要的设备号。
When you open them, you're connected to the device driver rather than a physical file, and the device driver is smart enough to know that separate processes should be handled separately.
当您打开它们时，您将连接到设备驱动程序而不是物理文件，并且设备驱动程序足够智能，知道应该分别处理不同的进程。
The same is true for the Linux /proc filesystem. Those aren't real files, just tightly controlled gateways to kernel information.
Linux /proc文件系统也是如此。这些不是真正的文件，只是严格控制的内核信息网关。
#2
37
It would be more correct to say that stdin, stdout, and stderr are "I/O streams" rather than files. As you've noticed, these entities do not live in the filesystem. But the Unix philosophy, as far as I/O is concerned, is "everything is a file". In practice, that really means that you can use the same library functions and interfaces (printf, scanf, read, write, select, etc.) without worrying about whether the I/O stream is connected to a keyboard, a disk file, a socket, a pipe, or some other I/O abstraction.
更正确的说法是stdin、stdout和stderr是“I/O流”，而不是文件。您已经注意到，这些实体并不存在于文件系统中。但就I/O而言，Unix的哲学是“一切都是文件”。实际上，这意味着您可以使用相同的库函数和接口(printf、scanf、read、write、select等)，而不必担心I/O流是否连接到键盘、磁盘文件、套接字、管道或其他一些I/O抽象。
Most programs need to read input, write output, and log errors, so stdin, stdout, and stderr are predefined for you, as a programming convenience. This is only a convention, and is not enforced by the operating system.
大多数程序需要读取输入、写输出和日志错误，所以stdin、stdout和stderr是为您预先定义的，作为编程的方便。这只是一个约定，操作系统不强制执行。
#3
18
I'm afraid your understanding is completely backwards. :)
恐怕你的理解完全颠倒了。:)
Think of "standard in", "standard out", and "standard error" from the program's perspective, not from the kernel's perspective.
从程序的角度考虑“标准in”、“标准out”和“标准错误”，而不是从内核的角度。
When a program needs to print output, it normally prints to "standard out". A program typically prints output to standard out with printf, which prints ONLY to standard out.
当程序需要打印输出时，它通常打印为“标准输出”。一个程序通常用printf打印输出到标准输出，而printf只输出到标准输出。
When a program needs to print error information (not necessarily exceptions, those are a programming-language construct, imposed at a much higher level), it normally prints to "standard error". It normally does so with fprintf, which accepts a file stream to use when printing. The file stream could be any file opened for writing: standard out, standard error, or any other file that has been opened with fopen or fdopen.
当程序需要打印错误信息(不一定是异常，这些是编程语言构造，在更高的级别上强加)时，它通常打印为“标准错误”。它通常使用fprintf，它接受在打印时使用的文件流。文件流可以是任何打开用于写入的文件:标准输出、标准错误，或者任何其他使用fopen或fdopen打开的文件。
"standard in" is used when the file needs to read input, using fread or fgets, or getchar.
当文件需要使用fread或fget或getchar来读取输入时，使用“standard in”。
Any of these files can be easily redirected from the shell, like this:
任何这些文件都可以从shell中轻松重定向，如下所示:
cat /etc/passwd > /tmp/out # redirect cat's standard out to /tmp/foo
cat /nonexistant 2> /tmp/err # redirect cat's standard error to /tmp/error
cat < /etc/passwd # redirect cat's standard input to /etc/passwd
Or, the whole enchilada:
或者,整个墨西哥菜:
cat < /etc/passwd > /tmp/out 2> /tmp/err
There are two important caveats: First, "standard in", "standard out", and "standard error" are just a convention. They are a very strong convention, but it's all just an agreement that it is very nice to be able to run programs like this: grep echo /etc/services | awk '{print $2;}' | sort and have the standard outputs of each program hooked into the standard input of the next program in the pipeline.
有两个重要的注意事项:第一，“标准in”、“标准out”和“标准错误”只是一种约定。他们是一个非常强大的公约,但都只是一项协议,非常高兴能够运行程序是这样的:grep回波/ etc / services | awk的{打印2美元;} |排序和每个程序的标准输出连接到管道中的下一个程序的标准输入。
Second, I've given the standard ISO C functions for working with file streams (FILE * objects) -- at the kernel level, it is all file descriptors (int references to the file table) and much lower-level operations like read and write, which do not do the happy buffering of the ISO C functions. I figured to keep it simple and use the easier functions, but I thought all the same you should know the alternatives. :)
第二,我给的标准ISO C函数处理文件流对象(文件*)——在内核层,这是所有的文件描述符(int引用文件表)和更低级别的操作,比如读和写,不做幸福的缓冲ISO C函数。我想保持简单，使用更简单的函数，但是我认为你应该知道其他的方法。:)
#4
7
stdin
Reads input through the console (e.g. Keyboard input). Used in C with scanf
通过控制台读取输入(例如键盘输入)。在C中与scanf一起使用
scanf(<formatstring>,<pointer to storage> ...);
stdout
Produces output to the console. Used in C with printf
生成到控制台的输出。在C中与printf一起使用
printf(<string>, <values to print> ...);
stderr
Produces 'error' output to the console. Used in C with fprintf
向控制台输出“错误”输出。用于C和fprintf
fprintf(stderr, <string>, <values to print> ...);
Redirection
The source for stdin can be redirected. For example, instead of coming from keyboard input, it can come from a file (echo < file.txt ), or another program ( ps | grep <userid>).
可以重定向stdin的源。例如，它不是来自键盘输入，而是来自一个文件(echo < file)。或另一个程序(ps | grep
The destinations for stdout, stderr can also be redirected. For example stdout can be redirected to a file: ls . > ls-output.txt, in this case the output is written to the file ls-output.txt. Stderr can be redirected with 2>.
stdout、stderr的目的地也可以重定向。例如，stdout可以重定向到一个文件:ls。> ls-output。txt，在本例中输出被写入文件ls-out .txt。Stderr可以重定向到2>。
#5
7
As a complement of the answers above, here is a sum up about Redirections: 
作为以上答案的补充，以下是关于重定向的总结:
#6
3
Using ps -aux reveals current processes, all of which are listed in /proc/ as /proc/(pid)/, by calling cat /proc/(pid)/fd/0 it prints anything that is found in the standard output of that process I think. So perhaps,
使用ps -aux可以显示当前进程，它们都列在/proc/ as /proc/(pid)/中，通过调用cat /proc/(pid)/fd/0，它可以打印在该进程的标准输出中找到的任何内容。因此,或许,
/proc/(pid)/fd/0 - Standard Output File
/proc/(pid)/fd/1 - Standard Input File
/proc/(pid)/fd/2 - Standard Error File
/proc/(pid)/fd/0 -标准输出文件/proc/(pid)/fd/1 -标准输入文件/proc/(pid)/fd/2 -标准错误文件
for example
例如
But only worked this well for /bin/bash other processes generally had nothing in 0 but many had errors written in 2
但是，只有在/bin/bash中，其他进程通常没有0，但是很多错误都是在2中编写的。
#7
2
I think people saying stderr should be used only for error messages is misleading. It should also be used for informative messages that are meant for the user running the command and not for any potential downstream consumers of the data (i.e. if you run a shell pipe chaining several commands you do not want informative messages like "getting item 30 of 42424" to appear on stdout as they will confuse the consumer, but you might still want the user to see them.
我认为人们说stderr应该只用于错误信息是有误导性的。还应该用于信息性消息意味着运行命令的用户,而不是对任何潜在的下游消费者的数据(即如果你运行一个壳管链接几个命令,您不希望的消息就像“42424”30项出现在stdout作为他们会迷惑消费者,但你可能仍希望用户看到他们。
See http://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout for historical rationale:
参见http://www.jstorimer.com/blogs/workingwithcode/7766119-when- use-stderr-instead of-stdout了解历史的基本原理:
"All programs placed diagnostics on the standard output. This had always caused trouble when the output was redirected into a file, but became intolerable when the output was sent to an unsuspecting process. Nevertheless, unwilling to violate the simplicity of the standard-input-standard-output model, people tolerated this state of affairs through v6. Shortly thereafter Dennis Ritchie cut the Gordian knot by introducing the standard error file. That was not quite enough. With pipelines diagnostics could come from any of several programs running simultaneously. Diagnostics needed to identify themselves."
所有程序都在标准输出上放置诊断信息。当输出被重定向到一个文件时，这总是会引起麻烦，但是当输出被发送到一个不知情的进程时，这就变得难以忍受。尽管如此，人们不愿违背标准输入-标准输出模型的简单性，他们通过v6容忍了这种情况。此后不久，丹尼斯·里奇引入了标准的错误文件，打破了僵局。这还不够。对于管道，诊断可以来自同时运行的多个程序中的任何一个。诊断需要识别他们自己。
#8
0
A file with associated buffering is called a stream and is declared to be a pointer to a defined type FILE. The fopen() function creates certain descriptive data for a stream and returns a pointer to designate the stream in all further transactions. Normally there are three open streams with constant pointers declared in the header and associated with the standard open files. At program startup three streams are predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). When opened the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device
具有关联缓冲的文件称为流，并声明为指向已定义类型文件的指针。函数的作用是:为流创建特定的描述性数据，并返回一个指针，用于在所有后续事务中指定流。通常有三个开放流，在头中声明常量指针，并与标准开放文件相关联。在程序启动时，三个流是预定义的，不需要显式地打开:标准输入(用于读取常规输入)、标准输出(用于写入常规输出)和标准错误(用于写入诊断输出)。打开时，标准错误流没有被充分缓冲;当且仅当可以确定流不引用交互式设备时，标准输入和标准输出流将被充分缓冲
https://www.mkssoftware.com/docs/man5/stdio.5.asp
https://www.mkssoftware.com/docs/man5/stdio.5.asp
#9
0
stderr will not do IO Cache buffering so if our application need to print critical message info (some errors ,exceptions) to console or to file use it where as use stdout to print general log info as it use IO Cache buffering there is a chance that before writing our messages to file application may close ,leaving debugging complex
stderr不会IO缓存缓冲,所以如果我们的应用程序需要打印关键消息信息(一些错误、异常)控制台或文件使用它,如使用标准输出打印通用日志信息,因为它使用IO缓存缓冲之前有机会编写消息文件应用程序可能被关闭,离开调试复杂
#1
150
Standard input - this is the file handle that your process reads to get information from you.
标准输入——这是进程读取的文件句柄，用于从您那里获取信息。
Standard output - your process writes normal information to this file handle.
标准输出—您的进程将正常信息写入此文件句柄。
Standard error - your process writes error information to this file handle.
标准错误——您的进程将错误信息写入这个文件句柄。
That's about as dumbed-down as I can make it :-)
那是我能做的最愚蠢的事:
Of course, that's mostly by convention. There's nothing stopping you from writing your error information to standard output if you wish. You can even close the three file handles totally and open your own files for I/O.
当然，这主要是根据惯例。如果您愿意，没有什么可以阻止您将错误信息写入标准输出。您甚至可以完全关闭三个文件句柄，并为I/O打开自己的文件。
When your process starts, it should already have these handles open and it can just read from and/or write to them.
当您的进程开始时，它应该已经打开了这些句柄，并且它可以直接读取和/或写入这些句柄。
By default, they're probably connected to your terminal device (e.g., /dev/tty) but shells will allow you to set up connections between these handles and specific files and/or devices (or even pipelines to other processes) before your process starts (some of the manipulations possible are rather clever).
默认情况下，它们可能连接到您的终端设备(例如/dev/tty)，但是shell将允许您在进程开始之前在这些句柄和特定的文件和/或设备(甚至管道到其他进程)之间建立连接(一些可能的操作是相当聪明的)。
An example being:
一个例子:
my_prog <inputfile 2>errorfile | grep XYZ
which will:
将:
- create a process for
my_prog. - 为my_prog创建一个进程。
- open
inputfileas your standard input (file handle 0). - 打开inputfile作为标准输入(文件句柄为0)。
- open
errorfileas your standard error (file handle 2). - 打开errorfile作为标准错误(文件句柄2)。
- create another process for
grep. - 为grep创建另一个进程。
- attach the standard output of
my_progto the standard input ofgrep. - 将my_prog的标准输出附加到grep的标准输入。
Re your comment:
是你的评论:
When I open these files in /dev folder, how come I never get to see the output of a process running?
当我在/dev文件夹中打开这些文件时，为什么我从来没有看到一个进程的输出?
It's because they're not normal files. While UNIX presents everything as a file in a file system somewhere, that doesn't make it so at the lowest levels. Most files in the /dev hierarchy are either character or block devices, effectively a device driver. They don't have a size but they do have a major and minor device number.
因为它们不是普通的文件。虽然UNIX将所有内容都表示为某个文件系统中的一个文件，但这并不意味着它是最低级别的文件。/dev层次结构中的大多数文件都是字符或块设备，实际上是设备驱动程序。它们没有大小，但是有一个主要的和次要的设备号。
When you open them, you're connected to the device driver rather than a physical file, and the device driver is smart enough to know that separate processes should be handled separately.
当您打开它们时，您将连接到设备驱动程序而不是物理文件，并且设备驱动程序足够智能，知道应该分别处理不同的进程。
The same is true for the Linux /proc filesystem. Those aren't real files, just tightly controlled gateways to kernel information.
Linux /proc文件系统也是如此。这些不是真正的文件，只是严格控制的内核信息网关。
#2
37
It would be more correct to say that stdin, stdout, and stderr are "I/O streams" rather than files. As you've noticed, these entities do not live in the filesystem. But the Unix philosophy, as far as I/O is concerned, is "everything is a file". In practice, that really means that you can use the same library functions and interfaces (printf, scanf, read, write, select, etc.) without worrying about whether the I/O stream is connected to a keyboard, a disk file, a socket, a pipe, or some other I/O abstraction.
更正确的说法是stdin、stdout和stderr是“I/O流”，而不是文件。您已经注意到，这些实体并不存在于文件系统中。但就I/O而言，Unix的哲学是“一切都是文件”。实际上，这意味着您可以使用相同的库函数和接口(printf、scanf、read、write、select等)，而不必担心I/O流是否连接到键盘、磁盘文件、套接字、管道或其他一些I/O抽象。
Most programs need to read input, write output, and log errors, so stdin, stdout, and stderr are predefined for you, as a programming convenience. This is only a convention, and is not enforced by the operating system.
大多数程序需要读取输入、写输出和日志错误，所以stdin、stdout和stderr是为您预先定义的，作为编程的方便。这只是一个约定，操作系统不强制执行。
#3
18
I'm afraid your understanding is completely backwards. :)
恐怕你的理解完全颠倒了。:)
Think of "standard in", "standard out", and "standard error" from the program's perspective, not from the kernel's perspective.
从程序的角度考虑“标准in”、“标准out”和“标准错误”，而不是从内核的角度。
When a program needs to print output, it normally prints to "standard out". A program typically prints output to standard out with printf, which prints ONLY to standard out.
当程序需要打印输出时，它通常打印为“标准输出”。一个程序通常用printf打印输出到标准输出，而printf只输出到标准输出。
When a program needs to print error information (not necessarily exceptions, those are a programming-language construct, imposed at a much higher level), it normally prints to "standard error". It normally does so with fprintf, which accepts a file stream to use when printing. The file stream could be any file opened for writing: standard out, standard error, or any other file that has been opened with fopen or fdopen.
当程序需要打印错误信息(不一定是异常，这些是编程语言构造，在更高的级别上强加)时，它通常打印为“标准错误”。它通常使用fprintf，它接受在打印时使用的文件流。文件流可以是任何打开用于写入的文件:标准输出、标准错误，或者任何其他使用fopen或fdopen打开的文件。
"standard in" is used when the file needs to read input, using fread or fgets, or getchar.
当文件需要使用fread或fget或getchar来读取输入时，使用“standard in”。
Any of these files can be easily redirected from the shell, like this:
任何这些文件都可以从shell中轻松重定向，如下所示:
cat /etc/passwd > /tmp/out # redirect cat's standard out to /tmp/foo
cat /nonexistant 2> /tmp/err # redirect cat's standard error to /tmp/error
cat < /etc/passwd # redirect cat's standard input to /etc/passwd
Or, the whole enchilada:
或者,整个墨西哥菜:
cat < /etc/passwd > /tmp/out 2> /tmp/err
There are two important caveats: First, "standard in", "standard out", and "standard error" are just a convention. They are a very strong convention, but it's all just an agreement that it is very nice to be able to run programs like this: grep echo /etc/services | awk '{print $2;}' | sort and have the standard outputs of each program hooked into the standard input of the next program in the pipeline.
有两个重要的注意事项:第一，“标准in”、“标准out”和“标准错误”只是一种约定。他们是一个非常强大的公约,但都只是一项协议,非常高兴能够运行程序是这样的:grep回波/ etc / services | awk的{打印2美元;} |排序和每个程序的标准输出连接到管道中的下一个程序的标准输入。
Second, I've given the standard ISO C functions for working with file streams (FILE * objects) -- at the kernel level, it is all file descriptors (int references to the file table) and much lower-level operations like read and write, which do not do the happy buffering of the ISO C functions. I figured to keep it simple and use the easier functions, but I thought all the same you should know the alternatives. :)
第二,我给的标准ISO C函数处理文件流对象(文件*)——在内核层,这是所有的文件描述符(int引用文件表)和更低级别的操作,比如读和写,不做幸福的缓冲ISO C函数。我想保持简单，使用更简单的函数，但是我认为你应该知道其他的方法。:)
#4
7
stdin
Reads input through the console (e.g. Keyboard input). Used in C with scanf
通过控制台读取输入(例如键盘输入)。在C中与scanf一起使用
scanf(<formatstring>,<pointer to storage> ...);
stdout
Produces output to the console. Used in C with printf
生成到控制台的输出。在C中与printf一起使用
printf(<string>, <values to print> ...);
stderr
Produces 'error' output to the console. Used in C with fprintf
向控制台输出“错误”输出。用于C和fprintf
fprintf(stderr, <string>, <values to print> ...);
Redirection
The source for stdin can be redirected. For example, instead of coming from keyboard input, it can come from a file (echo < file.txt ), or another program ( ps | grep <userid>).
可以重定向stdin的源。例如，它不是来自键盘输入，而是来自一个文件(echo < file)。或另一个程序(ps | grep
The destinations for stdout, stderr can also be redirected. For example stdout can be redirected to a file: ls . > ls-output.txt, in this case the output is written to the file ls-output.txt. Stderr can be redirected with 2>.
stdout、stderr的目的地也可以重定向。例如，stdout可以重定向到一个文件:ls。> ls-output。txt，在本例中输出被写入文件ls-out .txt。Stderr可以重定向到2>。
#5
7
As a complement of the answers above, here is a sum up about Redirections:
作为以上答案的补充，以下是关于重定向的总结:
#6
3
Using ps -aux reveals current processes, all of which are listed in /proc/ as /proc/(pid)/, by calling cat /proc/(pid)/fd/0 it prints anything that is found in the standard output of that process I think. So perhaps,
使用ps -aux可以显示当前进程，它们都列在/proc/ as /proc/(pid)/中，通过调用cat /proc/(pid)/fd/0，它可以打印在该进程的标准输出中找到的任何内容。因此,或许,
/proc/(pid)/fd/0 - Standard Output File
/proc/(pid)/fd/1 - Standard Input File
/proc/(pid)/fd/2 - Standard Error File
/proc/(pid)/fd/0 -标准输出文件/proc/(pid)/fd/1 -标准输入文件/proc/(pid)/fd/2 -标准错误文件
for example
例如
But only worked this well for /bin/bash other processes generally had nothing in 0 but many had errors written in 2
但是，只有在/bin/bash中，其他进程通常没有0，但是很多错误都是在2中编写的。
#7
2
I think people saying stderr should be used only for error messages is misleading. It should also be used for informative messages that are meant for the user running the command and not for any potential downstream consumers of the data (i.e. if you run a shell pipe chaining several commands you do not want informative messages like "getting item 30 of 42424" to appear on stdout as they will confuse the consumer, but you might still want the user to see them.
我认为人们说stderr应该只用于错误信息是有误导性的。还应该用于信息性消息意味着运行命令的用户,而不是对任何潜在的下游消费者的数据(即如果你运行一个壳管链接几个命令,您不希望的消息就像“42424”30项出现在stdout作为他们会迷惑消费者,但你可能仍希望用户看到他们。
See http://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout for historical rationale:
参见http://www.jstorimer.com/blogs/workingwithcode/7766119-when- use-stderr-instead of-stdout了解历史的基本原理:
"All programs placed diagnostics on the standard output. This had always caused trouble when the output was redirected into a file, but became intolerable when the output was sent to an unsuspecting process. Nevertheless, unwilling to violate the simplicity of the standard-input-standard-output model, people tolerated this state of affairs through v6. Shortly thereafter Dennis Ritchie cut the Gordian knot by introducing the standard error file. That was not quite enough. With pipelines diagnostics could come from any of several programs running simultaneously. Diagnostics needed to identify themselves."
所有程序都在标准输出上放置诊断信息。当输出被重定向到一个文件时，这总是会引起麻烦，但是当输出被发送到一个不知情的进程时，这就变得难以忍受。尽管如此，人们不愿违背标准输入-标准输出模型的简单性，他们通过v6容忍了这种情况。此后不久，丹尼斯·里奇引入了标准的错误文件，打破了僵局。这还不够。对于管道，诊断可以来自同时运行的多个程序中的任何一个。诊断需要识别他们自己。
#8
0
A file with associated buffering is called a stream and is declared to be a pointer to a defined type FILE. The fopen() function creates certain descriptive data for a stream and returns a pointer to designate the stream in all further transactions. Normally there are three open streams with constant pointers declared in the header and associated with the standard open files. At program startup three streams are predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). When opened the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device
具有关联缓冲的文件称为流，并声明为指向已定义类型文件的指针。函数的作用是:为流创建特定的描述性数据，并返回一个指针，用于在所有后续事务中指定流。通常有三个开放流，在头中声明常量指针，并与标准开放文件相关联。在程序启动时，三个流是预定义的，不需要显式地打开:标准输入(用于读取常规输入)、标准输出(用于写入常规输出)和标准错误(用于写入诊断输出)。打开时，标准错误流没有被充分缓冲;当且仅当可以确定流不引用交互式设备时，标准输入和标准输出流将被充分缓冲
https://www.mkssoftware.com/docs/man5/stdio.5.asp
https://www.mkssoftware.com/docs/man5/stdio.5.asp
#9
0
stderr will not do IO Cache buffering so if our application need to print critical message info (some errors ,exceptions) to console or to file use it where as use stdout to print general log info as it use IO Cache buffering there is a chance that before writing our messages to file application may close ,leaving debugging complex
stderr不会IO缓存缓冲,所以如果我们的应用程序需要打印关键消息信息(一些错误、异常)控制台或文件使用它,如使用标准输出打印通用日志信息,因为它使用IO缓存缓冲之前有机会编写消息文件应用程序可能被关闭,离开调试复杂