답변:
파이프는 단순히 한 프로세스의 표준 출력을 다른 프로세스의 표준 입력에 연결하는 데 사용되는 프로세스 간 통신 (IPC) 메커니즘입니다.
예를 들어 파일에서 "pax"라는 단어를 검색하려는 경우가 있습니다.
cat filename | grep pax
그리고 네, grep파일을 직접 사용할 수 있다는 것을 알고 있지만 그것이 어떻게 작동하는지 설명하지 못합니까?
cat명령 의 표준 출력을 명령의 표준 입력에 연결합니다 grep. cat파일의 내용을 표준 출력으로 보내고 grep표준 입력에서 파일 (이 경우)을 읽습니다. 이와 같이 프로세스를 함께 연결하면 여러 파이프 세그먼트로 구성된 고유 한 도구를 만들 수 있습니다. 같은 것들:
show_users | grep pax | awk -F: '{print $4}' | tr '[a-z]' '[A-Z]' | cut -c1-20
깨진 파이프 발신자 여전히 통해 물건을 보내려고하는 동안 데이터 (보통) 수신기가 연결을 종료했다 하나이다.
예를 들어, 한 번에 한 페이지 씩보기 위해 호출기 프로그램을 통해 큰 파일을 보내는 경우 :
cat myfile | pager
다음을 CTRL-BREAK, 이것은이 발생할 수 있습니다 pager전에 프로세스가 입력 파이프를 종료 cat를 사용하여 완료했습니다. 이 깨진 파이프를 얻을 수있는 가능성 중 하나입니다.
복잡한 Google 검색 에서이 특정 문제는 임시 배포와 관련된 것으로 보이며 일반적으로 제공된 솔루션에는 대부분의 소프트웨어를 종료하고 대부분의 기기를 재부팅하는 것이 포함됩니다.
이 문제는 Apple에 문제를보고 할만큼 심각합니다. 그것에 대해 불평하는 개발자가 많을수록 문제를 해결할 가능성이 높아집니다.
pr -e4 -n ten-thousand-lines.c | sed 10q부러진 파이프로 끝납니다. prSIGPIPE 신호를 받았다고 귀찮게 하는지 여부 는 또 다른 문제입니다. 신호의 결과로 단순히 종료 될 수 있습니다 (제로가 아닌 종료 상태 생성).
|문자는 종종 파이프라고합니다. 다양한 유닉스 쉘 (내가 아는 것)에서 한 명령의 출력을 다른 명령의 입력으로 파이프하는 데 사용될 수있다.
cat myfile.txt | head
이 head명령은 입력의 처음 몇 줄만 표시합니다. 이 시점에서 입력을 닫습니다. 이로 인해 입력을 생성 한 명령에 문제가 발생합니다. 어디에 쓰는가? 이러한 상황이 있거나 독자가 통과하기 전에 쓰기 프로세스가 끝나는 상황을 "파손 된 파이프"라고합니다.
cat명령이 영원히 머 무르지 않도록하기 위해 UNIX 표준은 전송되는 특수 신호 ( SIGPIPE , 신호 13 )를 정의합니다 cat. 이 신호의 기본 동작은 프로세스를 cat종료하는 것입니다.
사용중인 응용 프로그램이 SIGPIPE를 포함한 모든 신호에 대해 신호 처리기를 설치하여 보이는 작은 팝업 메시지를 생성하는 것처럼 보입니다.
이 오류는 상당히 자주 발생하는 것 같습니다. /programming/490366/ad-hoc-deployment-issue-putpkt-write-failed-broken-pipe "... Xcode의 전화 통화 능력에 내부 오류가 있습니다. 당신이 잘못한 것을 의미합니다. 그것은 개발 시스템의 버그입니다. "
파이프는 Unix 시스템의 IPC 메커니즘입니다. 파이프에는 두 개의 끝 (읽기 끝 및 쓰기 끝)이 있습니다. 쓰기 엔드에 쓰여진 데이터는 읽기 엔드에서 읽을 수 있으며 쓰여진 순서대로 나옵니다.
유닉스 커맨드 라인 세계에서 파이프는 프로그램을 함께 연결하여 작업을 수행하는 매우 일반적인 방법입니다. 예를 들어 sed 's/foo/bar/g' fred.txt | grep -e 'bar.*baz'파일 fred.txt에서 문자열의 모든 인스턴스를 문자열 foo로 바꾸고 그 뒤에 몇 개의 문자 bar가 포함 된 행을 검색 한 다음 을 읽습니다 .barbaz
물론, 그다지 유용한 것은 아닙니다. 그러나 당신이 그것에 대해 생각한다면 모든 종류의 흥미로운 용도, 특히 당신이 awk또는 perl당신이 처분 할 수있는 프로그램을 가진 후에 그것을 어떻게 사용할 수 있는지 알 수 있다고 확신합니다 .
파이프 시스템은 아주 초기부터 유닉스의 일부였습니다. 파이프 라인의 프로세스가 종료되면 일반적으로 파이프 라인의 모든 프로그램이 종료되기를 원합니다. 이것은 기본적으로 파이프에 쓰는 프로세스가 읽기 끝의 프로세스가 종료 된 경우 SIGPIPE신호를 수신 한다는 것을 의미합니다 . 그리고 그 신호가 차단 write되면 파이프가 '파손'되었음을 나타내는 특수한 종류의 오류와 함께 실패합니다.
기본 처리 SIGPIPE는 프로세스를받는 프로세스를 종료시킵니다. 그리고 파이프 라인의 '헤드'가 아닌 경우 모든 SIGPIPE것이 체인을 통해 전파됩니다.
Xcode가 불평하는 것은 파이프로 이어지는 파이프로 무언가를하기 위해 서브 프로그램을 시작했으며 파이프가 파손 된 상태로 서브 프로그램이 예기치 않게 죽었다는 것입니다.
“파손 된”파이프는 한쪽 끝 close()이 만들어지고 다른 쪽 끝이 읽히거나 쓰여지는 곳입니다. 예를 들어 다음 쉘 명령에서
cat foo | less
cat프로세스 파이프의 쓰기 단부를 보유하고, less처리는 하나의 읽기. 판독기 프로세스가 파이프를 닫으면 파이프가 파손 된 것이므로 쓸모가 없습니다. 라이터 프로세스는 운영 체제에서 "브로큰 파이프"오류를 수신합니다.
cat완료 되 자마자) 독자는 정상적인 파일 끝을 보게됩니다.