나는 그것을 다양한 방법으로 보고 stdout사용 stderr했습니다. 내가 아는 한 그것은 일반적으로 stdout일반적인 정보 및 stderr오류 등에 사용됩니다. 그러나 stderr프로그램 자체와 관련된 정보(오류, 경고, 디버깅 등과는 관련이 없음)를 출력하고 디버깅 목적으로 사용하는 경우도 있습니다(후자가 필터링할 수 있도록 오류 스트림을 사용한다고 가정합니다). 디버깅) 및 stdout포함되어야 한다고 생각하는 더 심각한 경고가 있습니다 stderr.
stdout그렇다면 이것이 이상적인 사용으로 간주 되거나 stderr일반적인 출력 및 오류 외에 프로그램 출력과 관련된 것은 언제인지 궁금합니다 . 프로그램에 더 의존적입니까, 아니면 더 일반적입니까?
답변1
와 를 분리하는 이유는 우선 stdout프로그램 데이터 출력(파일에 저장되거나 파이프 등에 공급될 수 있음)과 진단 및 보풀( stderr터미널의 인간 운영자에게만 관심이 있음)을 구별하기 위한 것입니다. . (입력에 대해 동일한 작업을 수행하는 자동 방법은 없지만 대신 제어 터미널 장치를 열고 읽는 방식으로 약간의 문제를 겪으면서 수행할 수 있습니다 .) 따라서 stdin옵션이 있는 경우stdout무언가를 쓸 수 있는 in 등과 같은 재정의 옵션이 있습니다 .)stderr2>&1bash
답변2
때에 따라 다르지! 관련 요소는 stderr실패가 발생할 때 오류 메시지가 버퍼로 릴리스되는 것을 원하지 않기 때문에 기본값은 버퍼링되지 않는다는 것입니다. 반면 stdout기본값은 라인(터미널) 또는 블록(그렇지 않은 경우) 버퍼링됩니다. 오류로 인해 데이터 행이나 블록이 손실될 수 있지만 이 접근 방식이 더 효율적입니다. 다른 하나는 프로그램이 출력하는 것입니다. 무언가가 CSV 또는 JSON과 같은 특정 형식을 내보내는 경우 오류 메시지를 혼합하면 프로그램이 손상될 수 있습니다(또는 특정 형식으로 인코딩해야 하며 해당 형식인 경우). abort! abort! ), 다른 경우에는(대화형 메뉴 유형 시스템?) 오류 메시지를 다른 출력과 혼합하는 것이 그다지 중요하지 않을 수 있습니다.
답변3
누군가가 어느 시점에 귀하의 프로그램을 파이프라인에 넣을 것이라고 항상 가정하십시오.
$ inputProducer | yourProgram | outputConsumer
stderr또는 에 무엇인가를 타겟팅할지 고려할 때 stdout중요한 것은 콘텐츠가 (일반적으로) 관련성이 있는지 outputConsumer, 아니면 그것이 귀하의 삶을 더 어렵게 만들 것인지 여부입니다.
- 관련된:
stdout - 관련 없음:
stderr
( 더 나은 옵션임에도 불구하고 사람들이 로 리디렉션하는 것을 잊어버렸기 때문에 많은 버그 보고서가 stdout대신 으로 이동한다는 점에 유의하십시오 .)stderrstderr