stdin, stdout 및 stderr에 대해 혼란 스럽습니까?

stdin, stdout 및 stderr에 대해 혼란 스럽습니까?

---

나는이 세 파일의 목적과 다소 혼동됩니다. 내 이해가 정확 stdin하면 프로그램이 프로세스에서 작업을 실행하기 위해 요청에 쓰는 stdout파일, 커널이 출력을 쓰는 stderr파일 및 정보를 액세스하도록 요청하는 프로세스 가 파일이며 모든 예외가 입력됩니다. 이러한 파일이 실제로 발생하는지 확인하기 위해 이러한 파일을 열면 제안한 것이 아무것도 없습니다!

내가 알고 싶은 것은이 파일의 목적이 정확히 무엇인지, 기술 전문 용어가 거의없는 답입니다.

---

표준 입력 - 정보를 얻기 위해 프로세스가 읽는 파일 핸들 입니다.

표준 출력 -프로세스는이 파일 핸들에 일반 정보를 씁니다.

표준 오류 -프로세스가이 파일 핸들에 오류 정보를 씁니다.

그것은 내가 할 수있는 것처럼 바보처럼 보입니다 :-)

물론 그것은 대부분 관습에 따른 것입니다. 원하는 경우 오류 정보를 표준 출력에 쓰는 것을 막을 수있는 것은 없습니다. 세 개의 파일 핸들을 완전히 닫고 I / O를 위해 자신의 파일을 열 수도 있습니다.

프로세스가 시작되면 이러한 핸들이 이미 열려 있어야하며 핸들에서 읽고 쓸 수 있습니다.

기본적으로 터미널 장치 (예 :)에 연결되어 /dev/tty있지만 프로세스를 시작하기 전에 이러한 핸들과 특정 파일 및 / 또는 장치 (또는 다른 프로세스의 파이프 라인) 사이의 연결을 설정할 수 있습니다 (일부 가능한 조작은 다소 영리합니다.)

예를 들면 다음과 같습니다.

my_prog <inputfile 2>errorfile | grep XYZ

어느 것이 :

• 에 대한 프로세스를 만듭니다 my_prog.
• inputfile표준 입력으로 엽니 다 (파일 핸들 0).
• errorfile표준 오류로 엽니 다 (파일 핸들 2).
• 에 대한 다른 프로세스를 만듭니다 grep.
• 의 표준 출력 my_prog을의 표준 입력에 연결하십시오 grep.

---

당신의 의견을 다시 :

/ dev 폴더에서 이러한 파일을 열면 실행중인 프로세스의 출력을 어떻게 볼 수 없습니까?

정상적인 파일이 아니기 때문입니다. UNIX는 파일 시스템에서 모든 것을 파일로 제공하지만 가장 낮은 수준에서는 그렇게하지 않습니다. /dev계층 구조 에있는 대부분의 파일은 문자 또는 블록 장치이며 사실상 장치 드라이버입니다. 크기는 없지만 주 장치 번호와 부 장치 번호가 있습니다.

파일을 열면 실제 파일이 아닌 장치 드라이버에 연결되며 장치 드라이버는 별도의 프로세스를 개별적으로 처리해야한다는 것을 알기에 영리합니다.

Linux /proc파일 시스템 에서도 마찬가지입니다 . 그것들은 실제 파일이 아니며 커널 정보로 엄격하게 제어되는 게이트웨이입니다.

---

그런 말을하는 것이 더 정확한 것 stdin, stdout그리고 stderr오히려 파일보다 "I / O는 스트림"입니다. 알다시피, 이러한 엔티티는 파일 시스템에 존재하지 않습니다. 그러나 I / O에 관한 한 유닉스의 철학은 "모든 것이 파일"입니다. 실제로, 같은 라이브러리 함수와 인터페이스를 (사용할 수있는 정말 수단 printf, scanf, read, write, select는 I / O 스트림은 키보드, 디스크 파일, 소켓, 파이프에 연결되어 있는지 여부에 대한 걱정없이, 등) 또는 다른 I / O 추상화.

대부분의 프로그램은 이렇게 입력, 쓰기 출력 및 로그 오류, 읽을 필요 stdin, stdout및 stderr프로그래밍 편의를 위해, 당신을 위해 미리 정의되어 있습니다. 이것은 규칙 일 뿐이며 운영 체제에 의해 시행되지 않습니다.

---

위의 답변을 보완하기 위해 다음은 리디렉션에 대한 요약입니다.

편집 :이 그래픽은 완전히 정확하지 않지만 왜 그런지 잘 모르겠습니다 ...

그래픽은 2> & 1은 &>와 동일한 효과를 나타냅니다.

ls Documents ABC > dirlist 2>&1
#does not give the same output as 
ls Documents ABC > dirlist &>

---

이해가 완전히 뒤 떨어질 까봐 걱정됩니다. :)

커널의 관점이 아니라 프로그램의 관점 에서 "표준 입력", "표준 출력"및 "표준 오류"를 생각하십시오 .

프로그램이 출력을 인쇄해야 할 경우 일반적으로 "표준 출력"으로 인쇄합니다. 프로그램은 일반적으로 표준 출력으로 만 출력하고 표준 출력으로 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.

"standard in" is used when the file needs to read input, using fread or fgets, or getchar.

Any of these files can be easily redirected from the shell, like this:

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.

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. :)

---

stdin

Reads input through the console (e.g. Keyboard input). Used in C with scanf

scanf(<formatstring>,<pointer to storage> ...);

stdout

Produces output to the console. Used in C with printf

printf(<string>, <values to print> ...);

stderr

Produces 'error' output to the console. Used in C with 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>).

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>.

---

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.

See this for historical rationale:

"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."

---

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,

/proc/(pid)/fd/0 - Standard Output File
/proc/(pid)/fd/1 - Standard Input File
/proc/(pid)/fd/2 - Standard Error File

for example

But only worked this well for /bin/bash other processes generally had nothing in 0 but many had errors written in 2

---

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

---

For authoritative information about these files, check out the man pages, run the command on your terminal.

$ man stdout 

But for a simple answer, each file is for:

stdout for a stream out

stdin for a stream input

stderr for printing errors or log messages.

Each unix program has each one of those streams.

---

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

참고 URL : https://stackoverflow.com/questions/3385201/confused-about-stdin-stdout-and-stderr