진행률 보고서 / 로깅 정보가 stderr 또는 stdout에 속해 있습니까?

진행 보고서 및 로깅 정보 ( "Doing foo; foo done"등)를 인쇄해야하는 공식 POSIX, GNU 또는 기타 지침이 있습니까? 개인적으로, 나는 stdout을 리디렉션하고 프로그램의 실제 출력 만 가져올 수 있도록 stderr에 작성하는 경향이 있습니다. 최근에 진행 보고서가 실제로 오류가 아니며 오류 메시지 만 stderr에 인쇄해야하기 때문에 이것이 좋은 습관이 아니라고 들었습니다.

두 위치 모두 의미가 있으며, 물론 당신이하는 일의 세부 사항에 따라 하나 또는 다른 것을 선택할 수 있지만, 일반적으로 인정되는 표준이 있는지 알고 싶습니다. POSIX, GNU 코딩 표준 또는 기타 널리 인정되는 모범 사례 목록에서 특정 규칙을 찾을 수 없었습니다.

비슷한 질문이 있지만이 정확한 문제를 해결하지 못합니다.

• 쉘 스크립트에서 stderr로 리디렉션을 사용하는 경우 : 허용되는 대답은 내가하는 경향이 있음을 나타냅니다. 프로그램의 최종 출력을 stdout에 유지하고 stderr에 다른 것을 유지하십시오. 그러나 이것은 주장에 의해 뒷받침되지만 사용자의 의견으로 제시됩니다.

• 사용법 메시지가 stderr 또는 stdout으로 이동해야합니까? : 이것은 메시지를 돕기위한 것이지만 GNU 코딩 표준을 인용합니다. 이것은 내가 찾고있는 일종의 메시지 일뿐입니다.

따라서 진행률 보고서 및 기타 정보 메시지 (프로그램의 실제 출력에 포함되지 않은)를 인쇄해야하는 공식적인 규칙이 있습니까?

Posix는 표준 스트림 을 다음과 같이 정의합니다 .

프로그램 시작시 표준 입력 (일반 입력 읽기), 표준 출력 (일반 출력 쓰기) 및 표준 오류 (진단 출력 쓰기 )의 세 가지 스트림을 미리 정의해야하며 명시 적으로 열 필요는 없습니다 . 열면 표준 오류 스트림이 완전히 버퍼링되지 않습니다. 표준 입력 및 표준 출력 스트림은 스트림이 대화식 장치를 참조하지 않는 것으로 결정될 수있는 경우에만 완전히 버퍼링됩니다.

GNU C 라이브러리 유사 표준 스트림을 설명합니다 :

변수 : FILE * stdout
표준 출력 스트림으로 프로그램의 일반 출력에 사용됩니다.

변수 : FILE * stderr
표준 오류 스트림으로, 프로그램이 발행 한 오류 메시지 및 진단에 사용됩니다.

따라서 표준 정의에는 "기존 / 정상 출력"및 "진단 / 오류 출력"이외의 스트림 사용에 대한 지침이 거의 없습니다. 실제로 진행률 표시기가 문제가되는 이러한 스트림 중 하나 또는 둘 모두를 파일 및 파이프 라인으로 리디렉션하는 것이 일반적입니다. . 일부 시스템 은 출력을 모니터링 stderr 하고 문제의 징후로 간주합니다. 따라서 보조 보조 진행 정보는 어느 스트림에서나 문제가됩니다.

대신 무조건으로 진행 표시기를 보내는 중 표준 스트림, 그 진행 출력에만 적합 인식하는 것이 중요 상호 작용 스트림. 이를 염두에두고 스트림이 대화 형인지 (예 :로 isatty()) 또는 명령 줄 옵션으로 명시 적으로 활성화 된 경우 에만 진행 카운터를 작성하는 것이 좋습니다 . % 완료 바와 같이 이해하기 위해 터미널 업데이트 동작에 의존하는 진행 미터에 특히 중요합니다.

매우 간단한 진행 메시지 ( "Starting X"... "Done with X")의 경우 비 대화식 스트림에 대해서도 출력을 포함하는 것이 더 합리적입니다. 이 경우로 검색 grep또는 페이징 less또는 모니터링과 같이 사용자가 스트림과 상호 작용하는 방법을 고려하십시오 tail -f. 이러한 상황에서 진행 메시지를 보는 것이 합리적이라면에서보다 쉽게 ​​사용할 수 있습니다 stdout.

POSIX 는 표준 오류를 다음과 같이 정의합니다

진단 출력용

오류 메시지로만 사용되는 것은 아닙니다. 진행 정보를 진단 출력으로 간주하므로 표준 오류에 속합니다.

POSIX는 Shell and Utilities , 1.4의 "진단 정보"에 대해 약간 더 구체적입니다 . 유틸리티 설명 기본값 (강조 광산) :

STDERR

STDERR 섹션은 유틸리티의 표준 오류 출력을 설명합니다. 유틸리티가 의도적으로 보낸 메시지 만 설명합니다. 표준 오류에 터미널을 사용하면 표준 오류 출력을 기록하는 표준 유틸리티가 백그라운드에서 사용될 때 중지 될 수 있습니다. 이러한 이유로 응용 프로그램은 백그라운드에서 스크립트에 대화 형 기능을 사용해서는 안됩니다.

대부분의 유틸리티에 대한 진단 메시지 형식은 지정되어 있지 않지만이 POSIX.1-2008 볼륨으로 형식이 지정되지 않은 진단 및 정보 메시지의 언어 및 문화적 규칙은 LC_MESSAGES 및 [XSI] [옵션 시작] 설정의 영향을받습니다. ] NLSPATH. [옵션 끝]

표준 유틸리티의 지정된 표준 오류 출력은이 POSIX.1-2008 볼륨에서 제공하는 것을 제외하고이 POSIX.1-2008 볼륨에 정의 된 환경 변수의 존재 또는 값에 의존하지 않아야합니다.

기본 동작 :이 섹션이 "표준 오류는 진단 메시지에만 사용해야합니다."로 표시되면 달리 명시하지 않는 한 종료 상태에 오류가 있음을 나타내는 경우에만 진단 메시지가 표준 오류로 전송 됨을 의미합니다. 이 POSIX.1-2008 볼륨에서 설명한대로 유틸리티가 사용되었습니다.

이 섹션이 "사용되지 않음"으로 표시되면 POSIX.1-2008의이 볼륨에 설명 된대로 유틸리티를 사용할 때 표준 오류를 사용하지 않아야합니다.

IANASL,하지만 유틸리티가 오류 종료 코드를 반환하는 경우에만 stderr이 출력을 의미한다는 것을 해석합니다. 성공적인 실행을위한 정상적인 이벤트 과정이 아니므로 오류가 발생 하지 않는 한 (물론, 달리 지정되지 않은 경우) POSIX 유틸리티가 진행 정보를 인쇄하지 않아야합니다 .

제외 원칙에 따르면 stderr로만 갈 수 있습니다. 그렇습니다. 스티븐 키트가 제공 한 POSIX 사양에 대한 링크를 넘어서서 stderr이 진단 목적임을 나타내는 공식 사양에 대해 질문 한 것을 알고 있습니다.

더 중요한 점은 stdin과 stdout이 진행 보고서를 stdout으로 인쇄하는 것을 허용하지 않는 기능을 가지고 있다는 것입니다. 물론 Unix 쉘 명령에서 부작용이 아니라 강력한 파이프 라이닝 방식의 핵심 인 파이프 시퀀스를 형성합니다. .

그래서. 프로그램의 실제 "페이로드"를 제외하고는 stdout에 속하지 않습니다. 프로그램에 출력이 없으면 stdout으로 이동하지 않아야합니다. 이것은 진행 보고서를 포함하여 다른 모든 것에 대한 stderr을 남깁니다 .

물론, 이것은 구멍을 남깁니다. 아마도 "stdfluff"또는 출력이나 오류가 아닌 진행률 보고서, 디버깅 및 그와 비슷한 것을 갖는 것이 좋을 것입니다. 사실, 아무것도하지 않아도됩니다. 즉, 진행 상황을 파일 디스크립터 3에 인쇄 할 수 있습니다. 예 :

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'

출력이 없습니다. (*)

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'  3>&1
hello

이것은 fd-3으로 인쇄되고 stdout으로 리디렉션됩니다.

(*) 첫 번째 예제는 출력을 생성하지 않지만 여전히 약간 가져옵니다. 는 open실패하고 $!포함됩니다 no such file or directory; 예를 들어 이것을 예로 들면, 본격적으로 이와 같이 사용되는 것은 아닙니다. 실제 프로그램에서이 경로를 사용하려면 /dev/fd/3사용 가능 여부를 테스트 하고 진행률 보고서를 활성화할지 여부에 대한 힌트로 사용할 수 있습니다. 당신 open은 실제 파일과 같은 것들에 대해 자신 의 혼란에 빠지지 않도록 꽤 일찍해야 할 것입니다 ...

사용 메시지는 사용자가 호출 한 경우 stdout --help으로, 실수 한 경우 stderr 로 이동해야합니다 . 무조건 stderr에 인쇄하는 것은 호출기 / grep 등으로보기가 더 어려워지기 때문에 불쾌합니다.

또한 세 번째 방법을 제안 할 수 있습니다. 진행률 보고서 / 스피너 등을 위해 / dev / tty를여십시오.