bash 파이프 라인에서`yes`를 사용하면 왜 무한 루프가 발생합니까?

문서에 따르면 bash는 파이프 라인의 모든 명령이 실행을 마칠 때까지 기다렸다가 계속합니다.

쉘은 값을 리턴하기 전에 파이프 라인의 모든 명령이 종료되기를 기다립니다.

그렇다면 왜 명령 yes | true이 즉시 완료됩니까? yes루프를 영원히 유지 해서는 안되며 파이프 라인이 다시 반환되지 않아야합니까?

그리고 subquestion는 다음에 따라 POSIX 사양 , 쉘 파이프 라인은 명령이 완료 모든 때까지 마지막 명령이 완료 또는 대기 후 중 하나를 반환 할 수도 있습니다. 이런 의미에서 일반적인 쉘은 다른 동작을합니까? yes | true영원히 반복 되는 껍질이 있습니까?

때 true종료가 파이프의 읽기 측이 폐쇄되어 있지만, yes쓰기 측에 쓰기를 시도 계속합니다. 이 조건을 "깨진 파이프"라고하며 커널이에 SIGPIPE신호를 보냅니다 yes. yes이 신호에 대해 특별한 것은 없기 때문에 죽을 것입니다. 신호를 무시하면 write오류 코드와 함께 호출이 실패합니다 EPIPE. 이를 수행하고 EPIPE기록을 중지 하기 위해 준비해야하는 프로그램 은 무한 루프로 진행됩니다.

strace yes | true¹ 을 수행 하면 커널이 두 가지 가능성을 준비하는 것을 볼 수 있습니다.

write(1, "y\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\n"..., 4096) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=17556, si_uid=1000} ---
+++ killed by SIGPIPE +++

strace디버거 API를 통해 이벤트를보고 있는데, 먼저 오류와 함께 반환되는 시스템 호출 및 신호에 대해 알려줍니다. 에서 yes의 관점하지만, 먼저 신호가 발생합니다. 기술적으로 커널이 사용자 공간으로 제어를 리턴 한 후 더 많은 기계 명령어가 실행되기 전에 신호가 전달되므로 writeC 라이브러리 의 "래퍼 (wrapper)"기능이 설정 errno되어 애플리케이션으로 리턴 될 기회가 없습니다 .

¹ 안타깝게도 straceLinux에 따라 다릅니다. 대부분의 현대 유닉스는 비슷한 기능을 수행 하는 명령을 가지고 있지만 종종 다른 이름을 가지고 있으며 아마도 syscall 인수를 완전히 해독하지 않으며 때로는 루트에서만 작동합니다.

네 껍질이 있습니까? | 진실은 영원히 반복됩니까?

가능성은 이후 yes명령 파이프를 사용하고, 파이프가 파손되는 경우는 실패 할 것이다. sleep반면에 파이프를 사용하지 마십시오.

sleep 100000000 | true

적어도 100000000 초 동안 실행됩니다.