stdout 방법의 수수께끼 깊은 컬의 조사

안녕하세요ω╹๑ )
컬의 stdout 마니아?요즘 작업 중이에요 알겠습니다!웃다 웃다

어?그거 표준 출력 아니야?😇

일의 시작은certbot dns challeenge 때 "manual-auth-hook"안에서 진행되었다
컬의 행동에 불신을 느끼다😥
Let's Encerypt 인증서를 발행하는 과정에서 DNS Challenge를 사용했습니다.
다음 TXT 레코드를 편집하는 API 를 두드리는 중

curl -i -X PUT https://hoge.com/api/record/txt \
  -data "{\"value\":\"fooooo\"}" >> response_headers.log

당연히 아래의 결과를 얻기를 바란다

응답 헤드의 HTTP 상태 코드는 200

API 측 처리도 정상적으로 작동하며 아무 문제 없음

하지만 한 가지 궁금한 것은 manual-auth-hook의 실행 결과 중 하나가 표준 오류(stderr)를 확인했다는 것이다.
확인해 봤는데 거기에curl의 진도표 로그가 있어요.😱
(※ -s 선택을 통해 stderr의 출력을 무효화하여 제거

환경을 조사하다

프로그램 라이브러리
릴리즈
curl
7.65.1
libcurl
7.65.1
nghttp2
1.29.0
※ 조사 관련 프로그램 라이브러리만 기재

무슨 수수께끼가 그렇게 깊어?🤔

출력 HTTP 요청 상황의 진행표는 stderr로 처리됩니다.
HTTP가 요청한 결과(반응 헤드의 상태 코드가 200인지 여부)가 어떻든 간에 표준 오류로 처리한 것은 수수께끼라고 생각했기 때문이다(※ 도대체 내 주관적인 생각일 뿐)

말하기 시작하다

curl 측의 방법을 의심하는 것은 확인할 때의 셸 스크립트에 다른 stdout이 있다는 것이다.
그중에 진도표의 로그만 stderr로 간주됩니다.
왜냐면
이런 현상인 만큼 certbot 측의 행동이라기보다는 컬에 주목하는 게 좋을 것 같아 조사를 진행했다.

curl 출력 진도표

관리 또는 리디렉션을 통해 다른 처리 시스템을 통해 제어할 때

기타(조사 안 함

실제로 확인했어요.

우선 표준 출력과 표준 오류를 선별합니다

$ curl "https://zenn.dev" > stdout.log 2> stderr.log

stderr.로고 내용을 확인해 보도록 하겠습니다.

$ cat stderr.log
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  104k  100  104k    0     0   429k      0 --:--:-- --:--:-- --:--:--  429k

역시 기준이 틀렸어...😱

진도표는 표준 오류 처리 방법을 알고 웃는다

총결산

당연한 일인지 몰라서 신선하고 설레요 웃어요
예측만 했지만.
이어 "진도표는 사용자(개발자)가 원래 원하던 정보(응답하는 머리나 몸)와 다르기 때문에 선별하기 쉬운 규격을 표준 오류로 요구한다"고 덧붙였다.
이런 배경이 있지 않을까 싶어요.
그 일대는 아직 조사하지 않았으니 역사적 배경 따위도 잘 조사해야 한다!!