악어를 지나 또 한 마리의 하이젠버그

$> set -o pipefail

$> fortune | head -1 > /dev/null && echo "Повезло!" || echo "Вы проиграли"
Повезло!

$> fortune | head -1 > /dev/null && echo "Повезло!" || echo "Вы проиграли"
Вы проиграли

여기에 fortune 조건부 프로그램 exit(rand()).

설명해주실 수 있나요? 여기서 무슨 일이야??

서정적-역사적 여담

나는 이 Heisenbug를 처음 알게 된 것은 XNUMX년 전입니다. 그런 다음 FaxNET의 게이트웨이에 대해 다음을 통해 여러 유틸리티를 생성해야 했습니다. 파이프 FreeBSD에서 "체커 연주". 예상대로 나는 나 자신을 고급스럽고 경험이 풍부한 프로그래머라고 생각했습니다. 그래서 모든 일을 최대한 세심하고 세심하게 하려고 했고, 특히 오류 처리에 신경을 썼는데...

이전에 sendmail 및 uucp/uupc의 버그를 처리한 경험으로 인해 "철저한 오류 처리"에 대한 노력이 더해졌습니다. 그 이야기를 자세히 파고들 필요는 없지만, 저는 이 하이젠버그와 10주 동안 14~XNUMX시간 동안 씨름했습니다. 그래서 기억에 남았고 어제이 옛 지인이 다시 방문했습니다.

간략한 설명 답변

공익 사업 head 수 채널을 닫아줘 fortune сразу 첫 줄을 읽자마자. 만약에 fortune 두 개 이상의 라인을 출력한 다음 해당 호출을 write() 오류를 반환하거나 요청한 것보다 더 적은 바이트가 출력된다는 보고를 합니다. 차례로, 신중한 오류 처리를 통해 작성되었습니다. fortune 종료 상태에 이 상황을 반영할 권리가 있습니다. 그러다가 설치로 인해 set -o pipefail 작동합니다 || echo "Вы проиграли".

그러나, head 제 시간에 못 갈 수도 있어 전에 닫다 fortune 데이터 출력이 완료됩니다. 그러면 작동할 거예요 && echo "Повезло!".

내 오늘 중 하나에 GNUMakefile 하나 있어요 단편:

echo '#define MDBX_BUILD_COMPILER "$(shell set -o pipefail; $(CC) --version | head -1 || echo 'Please use GCC or CLANG compatible compiler')"'

인간으로 번역됨

여기에서는 흔히 볼 수 있는 일입니다 GNU 메이크 и 세게 때리다 옵션을 사용하여 컴파일러 방식으로 --version 그가 누구인지 묻고 옵션이 지원되지 않으면 스텁이 삽입됩니다. "GCC 또는 CLANG 호환 컴파일러를 사용하십시오".

같은 상용구 어디서나 찾을 수 있습니다. 오래 전에 이곳에 나타났고 모든 곳에서 완벽하게 작동했습니다(Linux, Solaris, OSX, FreeBSD, WSL 등.). 그런데 어제에 알트리눅스 플랫폼에 엘브루스 2000(E2K) 나는 다음을 발견했다:

#define MDBX_BUILD_COMPILER "lcc:1.23.20:Sep--4-2019:e2k-v3-linux Please use GCC or CLANG compatible compiler"

솔직히 나는 나의 오랜 '지인'을 즉시 인식하지 못했습니다. 게다가 이 프로젝트는 이미 Elbrus와 Alt를 포함한 다양한 배포판에서 여러 번 테스트되었습니다. 다양한 컴파일러, GNU Make 및 bash 버전. 그러므로 나는 여기서 나의 실수를 보고 싶지 않았습니다.

문제를 재현하거나 무슨 일이 일어나고 있는지 이해하려고 할 때 더 이상한 일이 일어나기 시작했습니다.
명령줄 주문:

echo "#define MDBX_BUILD_COMPILER '$(set -o pipefail; LC_ALL=C cc --version | head -1 || echo "Please use GCC or CLANG compatible compiler")'"

때때로 추가 텍스트가 생성되기도 하지만 그렇지 않습니다... 종종 옵션 중 하나가 꽤 오랫동안 유지되는 경우가 있지만, 더 오래 찌르면 항상 둘 다 얻을 수 있습니다!

물론, strace 우리의 모든 것! 그리고 장황한 장황한 말을 입력했지만 Enter를 누를 시간이 없어서 나는 오랜 친구인 Mr. Heisenbug와 개발자들을 알아보았습니다. 컴파일러 나 자신도 25년 전, 노스탤지어… 그리고 나는 슬퍼하며 이 메모를 쓰기로 결정했습니다 😉

그건 그렇고, 자존심이 강한 것처럼 하이젠버그아래에 strace 재현하지 않는 것을 선호합니다.

무슨 일이야?

• 공익 사업 head 요청된 행 수를 읽는 즉시 읽고 있는 채널을 닫을 권리가 있습니다(또는 강제로).
• 데이터 생성 프로그램 작성자(이 경우 cc) 수 여러 줄을 인쇄하고 무료 여러 번의 통화를 통해 이 작업을 수행하세요. write().
• 면 독자는 작성자 측의 녹음이 끝나기 전에 자신의 채널을 닫을 시간을 갖게 되며, 그러면 작성자는 오류를 받게 됩니다.
• 작가 프로그램 권리가있다. 둘 다 채널 쓰기 오류를 무시하고 완료 코드에 반영합니다.
• 설치로 인해 set -o pipefail 파이프라인 완료 코드는 하나 이상의 요소에서 결과가 XNUMX이 아니면 XNUMX이 아니며(잘못됨) 작동합니다. || echo "Please use GCC or CLANG compatible compiler".

작성기 프로그램이 신호와 함께 작동하는 방식에 따라 차이가 있을 수 있습니다. 예를 들어 프로그램이 비정상적으로 종료될 수 있습니다(XNUMX이 아닌 종료/오류 종료 상태가 자동으로 생성됨). write() 요청 및 설정된 것보다 적은 바이트를 쓴 결과를 반환합니다. errno = EPIPE.

누가 탓할 것입니까?

설명된 사례의 경우 모든 것 조금. 오류 처리 cc (lcc:1.23.20:Sep—4-2019:e2k-v3-linux) ~이 아니다. 불필요한. 많은 경우에는 조심스럽게 실수하는 것이 더 낫습니다. 하지만 이렇게 하면 전통적인 동작을 위해 설계된 상용구에 갑작스러운 결함이 노출됩니다.

무엇을해야 하는가?

잘못된:

fortune | head -1 && echo "Повезло, но вы рискуете!" || echo "WTF?"

올바르게 :

1. (fortune && echo "Успешно" || echo "Ошибка") | head -1

   여기서 파이프의 조기 닫기는 중첩된 파이프라인(괄호 "내부")을 서비스할 때 명령 해석기에 의해 처리됩니다. 따라서 만약에 fortune 상태에서 닫힌 채널에 쓰는 동안 오류를 보고한 다음 출력합니다. || echo "Ошибка" 채널이 이미 닫혀 있기 때문에 아무데도 갈 수 없습니다.

2. fortune | cat - | head -1 && echo "Успешно" || echo "Ошибка"

   유틸리티는 다음과 같습니다. cat 오류를 무시하기 때문에 댐퍼 역할을 합니다. EPIPE 탈퇴시. 결론은 이 정도면 충분하다 fortune 작고(여러 줄) 채널 버퍼에 맞습니다(대부분의 OS ≥512K에서 64바이트 ~ 4K). 그렇지 않으면 문제가 다시 발생할 수 있습니다.

올바르게 처리하는 방법 EPIPE 그리고 다른 녹음 오류?

단 하나의 올바른 솔루션은 없지만 간단한 권장 사항이 있습니다.

• EPIPE 필수 처리해야 함 (종료 상태에 반영) 무결성이 필요한 데이터를 출력할 때. 예를 들어 아카이버 또는 백업 유틸리티가 작동하는 동안입니다.
• EPIPE 무시하는 것이 낫다 정보 및 보조 메시지를 표시할 때. 예를 들어 옵션에 대한 정보를 표시하는 경우 --help 또는 --version.
• 개발 중인 코드를 이전 파이프라인에서 사용할 수 있는 경우 | head, 그런 다음 EPIPE 무시하는 것이 좋으며, 그렇지 않은 경우 처리하여 종료 상태에 반영하는 것이 좋습니다.

이 기회를 빌어 팀원들에게 감사의 말씀을 전하고 싶습니다. MCST и 알트리눅스 훌륭한 생산적인 작업을 위해. 당신의 결심은 놀랍습니다!
계속 힘내세요 Camarades, 위로 가을에 모임!

감사 베레즈 오타 및 오류를 수정하기 위해.
KDPV의 조지 A.

출처 : habr.com