One more Heisenbug мимо крокодил

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

Здесь fortune условная программа без exit(rand()).

Cможете объяснить?

В одном из моих сегодняшних GNUMakefile есть такой фрагмент:

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

Подобный boilerplate можно встретить где угодно. В этом месте он появился давно и прекрасно везде работал (Linux, Solaris, OSX, FreeBSD, WSL и т.д.). Но вчера в AltLinux на платформе Эльбру́с 2000 (E2K) я заметил:

#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 наше всё! И вот набрав strace-тираду, но не успев нажать Enter я узнал своего старого знакомого мистера Гейзенбага, а в разработчиках компилятора себя самого 25 лет назад, Nostalgie… И решил взгрустнуть написать эту заметку 😉

Кстати, как любой уважающий себя Гейзенбаг, под 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 | cat - | head -1 && echo "Успешно" || echo "Ошибка"

Либо:

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

---

Пользуясь случаем хочу выразить благодарность коллективам МЦСТ и AltLinux за огромную результативную работу. Ваша целеустремлённость восхищает!
Так держать Camarades, до встречи осенью!

КДПВ от Георгий А.