$> set -o pipefail
$> fortune | head -1 > /dev/null && echo "Повезло!" || echo "Вы проиграли"
Повезло!
$> fortune | head -1 > /dev/null && echo "Повезло!" || echo "Вы проиграли"
Вы проигралиТут fortune умоўная праграма без exit(rand()).
Зможаце растлумачыць што тут глючыць?
Лірычна-гістарычны адступ
Першы раз з гэтым Гейзенбагам я пазнаёміўся чвэрць стагоддзя таму. Тады для шлюза ў FaxNET патрабавалася зрабіць некалькі ўтыліт праз «якія граюць у шашкі» пад FreeBSD. Як належыць, я лічыў сябе прасунутым і досыць дасведчаным праграмістам. Таму меў намер зрабіць усё максімальна акуратна і старанна, надаўшы адмысловую ўвагу апрацоўцы памылак…
Стараннасці ў стараннай апрацоўцы памылак мне тады дадаў папярэдні досвед барацьбы з багамі ў sendmail і uucp/uupc. Апускацца ў дэталі той гісторыі сэнсу няма, але змагаўся з гэтым Гейзенбагам я тыдні два па 10-14 гадзін. Таму запомнілася, і вось учора гэты стары знаёмы зноў зазірнуў у госці.
TL;DR Адказ
ўтыліта head можа закрыць канал ад fortune адразу як толькі прачытае першы радок. Калі fortune выводзіць больш за адзін радок, то адпаведны выклік write() верне памылку, альбо паведаміць аб вывадзе меншай колькасці байт чым запытана. У сваю чаргу, напісаная са стараннай апрацоўкай памылак fortune мае права адлюстраваць гэтую сітуацыю ў сваім статусе выхаду. Тады з-за ўстаноўкі set -o pipefail адпрацуе || echo "Вы проиграли".
Аднак, head можа не паспець закрыць да таго, як fortune скончыць вывад дадзеных. Тады адпрацуе && echo "Повезло!".
У адным з маіх сённяшніх ёсць такі :
echo '#define MDBX_BUILD_COMPILER "$(shell set -o pipefail; $(CC) --version | head -1 || echo 'Please use GCC or CLANG compatible compiler')"'У перакладзе на чалавечую
Тут звычайным для и спосабам у кампілятара пры дапамозе опцыі --version пытаецца хто ён такі, а калі опцыя не падтрымліваецца, то падстаўляецца заглушка "Please use GCC or CLANG compatible compiler".
падобны можна сустрэць дзе заўгодна. У гэтым месцы ён з'явіўся даўно і выдатна ўсюды працаваў (Linux, Solaris, OSX, FreeBSD, і г.д.). Але ўчора ў на платформе я заўважыў:
#define MDBX_BUILD_COMPILER "lcc:1.23.20:Sep--4-2019:e2k-v3-linux Please use GCC or CLANG compatible compiler"Прызнацца я не адразу разгледзеў старога "знаёмага". Больш за тое, праект ужо шматразова правяраўся на "Эльбрусах" і пад масай розных дыстрыбутываў, у тым ліку з "Альтам". З рознымі кампілятарамі, версіямі 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 я пазнаў свайго старога знаёмага містэра Гейзенбага, а ў распрацоўшчыках сябе самога 25 гадоў таму, І вырашыў зажурыцца напісаць гэтую нататку 😉
Дарэчы, як любы які паважае сябе , пад strace аддае перавагу не прайгравацца.
Дык што ж адбываецца?
- ўтыліта
headмае права (хутчэй нават змушаная) зачыніць чытэльны канал, адразу як толькі прачытае запытаную колькасць радкоў. - Якая генеруе дадзеныя праграма-пісьменнік (у дадзеным выпадку
cc) можа выводзіць некалькі радкоў і вольная рабіць гэта з дапамогай некалькіх выклікаўwrite(). - Калі чытач паспее закрыць канал са свайго боку да заканчэння запісу на баку пісьменніка, то пісьменніку прыляціць памылка.
- Праграма-пісьменнік мае права як праігнараваць памылку запісу ў канал, так і адлюстраваць яе ў сваім кодзе завяршэння.
- З прычыны ўстаноўкі
set -o pipefailкод завяршэння канвеера будзе ненулявым (памылковым) пры ненулявым выніку хаця б ад аднаго элемента, і тады адпрацуе|| echo "Please use GCC or CLANG compatible compiler".
Могуць быць варыяцыі, у залежнасці ад таго як праграма-пісьменнік працуе з сігналамі. Напрыклад, праграма можа быць аварыйна завершана (з аўтаматычным фарміраваннем ненулявога/памылковага статусу завяршэння), альбо write() верне вынік аб запісе меншай колькасці байтаў чым запытана і ўсталюе errno = EPIPE.
Хто вінаваты?
У апісваным выпадку усё патроху. Апрацоўка памылак у cc (lcc:1.23.20:Sep—4-2019:e2k-v3-linux) не з'яўляецца залішняй. У шматлікіх выпадках лепш перапільнаваць, хоць гэта і выяўляе раптоўныя недахопы ў boilerplate разлічаным на традыцыйныя паводзіны.
Што рабіць?
няправільна:
fortune | head -1 && echo "Повезло, но вы рискуете!" || echo "WTF?"правільна:
-
(fortune && echo "Успешно" || echo "Ошибка") | head -1Тут ранняе закрыццё канала будзе апрацавана інтэрпрэтатарам каманд пры абслугоўванні ўкладзенага канвеера ("унутры" дужак). Адпаведна, калі
fortuneпаведаміць у статусе пра памылку запісу ў закрыты канал, то вывад|| echo "Ошибка"ужо нікуды не патрапіць, бо канал ужо зачынены. -
fortune | cat - | head -1 && echo "Успешно" || echo "Ошибка"Тут утыліта
catвыступае дэмпферам, бо ігнаруе памылкуEPIPEпры вывадзе. Гэтага дастаткова пакуль высноваfortuneневялікі (некалькі радкоў) і змяшчаецца ў канальным буферы (ад 512 байт да ≈64К, у большасці АС ≥4К). У адваротным выпадку праблема можа вярнуцца.
Як правільна апрацоўваць EPIPE і іншыя памылкі пры запісе?
Адзіна дакладнага рашэння няма, але ёсць простыя рэкамендацыі:
EPIPEпатрабуецца абавязкова апрацоўваць (і адлюстроўваць у статуце выйсця) пры выснове дадзеных патрабавальных цэласнасці. Напрыклад, падчас працы архіватараў ці ўтыліт рэзервовага капіявання.EPIPEлепш ігнараваць пры вывадзе інфармацыйных і дапаможных паведамленняў. Напрыклад, пры вывадзе інфармацыі па опцыях--helpабо--version.- Калі распрацоўваны код дапушчальна выкарыстоўваць у канвееры перад
| head, ТоEPIPEлепш ігнараваць, інакш лепш апрацоўваць і адлюстроўваць у статуце выйсця.
Карыстаючыся выпадкам хачу выказаць падзяку калектывам. и за вялікую дзейсную працу. Ваша мэтанакіраванасць захапляе!
Так трымаць Camarades, да !
Дзякуй за выпраўленне ачапятак і памылак.
КДПВ ад
Крыніца: habr.com