Конвейеры — бесплатный тест онлайн

Вопрос 1 из 20

Перед запуском фрагмента из раздела «Канал между процессами» нужен точный прогноз. Какой вывод об этом варианте можно сделать без догадок о внешнем контексте?

{ printf 'ok\n'; printf 'bad\n' >&2; } | grep ok

Когда нужен первый результат, встроенное ограничение grep -m1 избегает лишнего процесса head и неоднозначного SIGPIPE. grep получает только ok через stdout и печатает его; bad остаётся в stderr терминала. После получения одной строки head закрывает канал, и producer может завершиться по SIGPIPE; это нормальное короткое замыкание, а не обязательно дефект producer. При большом числе совпадений grep может получить SIGPIPE после завершения head, и pipefail превратит ожидаемое короткое замыкание в ошибку сценария. wc печатает 2, и файл также содержит две строки: tee пропустил данные дальше и сохранил копию.

Вопрос 2 из 20

Перед запуском фрагмента из раздела «Статусы команд конвейера» нужен точный прогноз. Какой разбор соответствует именно показанной последовательности команд?

false | true | false
status=("${PIPESTATUS[@]}")
printf '%s\n' "${status[*]}"

pipefail делает ненулевой статус tee видимым всему конвейеру, хотя для точной диагностики всё равно полезно сохранить PIPESTATUS. После получения одной строки head закрывает канал, и producer может завершиться по SIGPIPE; это нормальное короткое замыкание, а не обязательно дефект producer. Сохранённый массив содержит 1 0 1; копирование выполнено сразу, прежде чем другой вызов изменил PIPESTATUS. Явное 2>&1 перед каналом объединяет диагностику с данными, поэтому consumer должен уметь различать их или такое объединение следует избегать. После echo PIPESTATUS уже описывает сам echo, поэтому второй вывод не содержит исходные два статуса.

Вопрос 3 из 20

Перед запуском фрагмента из раздела «Разветвление потока через tee» нужен точный прогноз. Какое описание не приписывает фрагменту лишних гарантий?

printf 'a\nb\n' | tee /tmp/tee.$$ | wc -l
printf 'file=%s\n' "$(wc -l < /tmp/tee.$$)"
rm -f /tmp/tee.$$

После echo PIPESTATUS уже описывает сам echo, поэтому второй вывод не содержит исходные два статуса. wc печатает 2, и файл также содержит две строки: tee пропустил данные дальше и сохранил копию. Сохранённый массив содержит 1 0 1; копирование выполнено сразу, прежде чем другой вызов изменил PIPESTATUS. Если запись tee в artifact.bin не удалась, checksum всё ещё может завершиться успешно; без pipefail отказ промежуточной команды легко пропустить. После получения одной строки head закрывает канал, и producer может завершиться по SIGPIPE; это нормальное короткое замыкание, а не обязательно дефект producer.

Вопрос 4 из 20

Перед запуском фрагмента из раздела «Ошибки в цепочке» нужен точный прогноз. Не предполагая намерение автора, что можно утверждать об этой конструкции?

set +o pipefail
false | true
printf 'plain=%s\n' "$?"
set -o pipefail
false | true
printf 'strict=%s\n' "$?"

Печатаются plain=0 и strict=1: успешная последняя команда маскирует предыдущий отказ только без pipefail. При большом числе совпадений grep может получить SIGPIPE после завершения head, и pipefail превратит ожидаемое короткое замыкание в ошибку сценария. Статусы нужно скопировать немедленно и затем анализировать сохранённый массив, иначе диагностика уничтожит данные. После echo PIPESTATUS уже описывает сам echo, поэтому второй вывод не содержит исходные два статуса. Сохранённый массив содержит 1 0 1; копирование выполнено сразу, прежде чем другой вызов изменил PIPESTATUS.

Вопрос 5 из 20

Этот участок из темы «Канал между процессами» относится к практической части теста «Конвейеры». Какой вывод наиболее точно привязан к показанной реализации?

producer | head -n 1

Явное 2>&1 перед каналом объединяет диагностику с данными, поэтому consumer должен уметь различать их или такое объединение следует избегать. Если запись tee в artifact.bin не удалась, checksum всё ещё может завершиться успешно; без pipefail отказ промежуточной команды легко пропустить. Сохранённый массив содержит 1 0 1; копирование выполнено сразу, прежде чем другой вызов изменил PIPESTATUS. После получения одной строки head закрывает канал, и producer может завершиться по SIGPIPE; это нормальное короткое замыкание, а не обязательно дефект producer. Статусы нужно скопировать немедленно и затем анализировать сохранённый массив, иначе диагностика уничтожит данные.

Вопрос 6 из 20

Этот участок из темы «Статусы команд конвейера» относится к практической части теста «Конвейеры». Какое утверждение о поведении кода остаётся точным на граничном входе?

false | true
echo "${PIPESTATUS[*]}"
printf 'again:%s\n' "${PIPESTATUS[*]}"

При большом числе совпадений grep может получить SIGPIPE после завершения head, и pipefail превратит ожидаемое короткое замыкание в ошибку сценария. grep получает только ok через stdout и печатает его; bad остаётся в stderr терминала. Если запись tee в artifact.bin не удалась, checksum всё ещё может завершиться успешно; без pipefail отказ промежуточной команды легко пропустить. После echo PIPESTATUS уже описывает сам echo, поэтому второй вывод не содержит исходные два статуса. Статусы нужно скопировать немедленно и затем анализировать сохранённый массив, иначе диагностика уничтожит данные.

Вопрос 7 из 20

Этот участок из темы «Разветвление потока через tee» относится к практической части теста «Конвейеры». Что важно заметить в этом фрагменте до его включения в автоматизацию?

generate | tee artifact.bin | checksum

Явное 2>&1 перед каналом объединяет диагностику с данными, поэтому consumer должен уметь различать их или такое объединение следует избегать. После echo PIPESTATUS уже описывает сам echo, поэтому второй вывод не содержит исходные два статуса. Когда нужен первый результат, встроенное ограничение grep -m1 избегает лишнего процесса head и неоднозначного SIGPIPE. Если запись tee в artifact.bin не удалась, checksum всё ещё может завершиться успешно; без pipefail отказ промежуточной команды легко пропустить. pipefail делает ненулевой статус tee видимым всему конвейеру, хотя для точной диагностики всё равно полезно сохранить PIPESTATUS.

Вопрос 8 из 20

Этот участок из темы «Ошибки в цепочке» относится к практической части теста «Конвейеры». Что действительно гарантирует или, наоборот, не гарантирует эта конструкция?

set -euo pipefail
grep pattern file | head -n 1

Когда нужен первый результат, встроенное ограничение grep -m1 избегает лишнего процесса head и неоднозначного SIGPIPE. После echo PIPESTATUS уже описывает сам echo, поэтому второй вывод не содержит исходные два статуса. Сохранённый массив содержит 1 0 1; копирование выполнено сразу, прежде чем другой вызов изменил PIPESTATUS. При большом числе совпадений grep может получить SIGPIPE после завершения head, и pipefail превратит ожидаемое короткое замыкание в ошибку сценария. Явное 2>&1 перед каналом объединяет диагностику с данными, поэтому consumer должен уметь различать их или такое объединение следует избегать.

Вопрос 9 из 20

Разберите код без пробного запуска; его тема — «Канал между процессами». Какое суждение правильно описывает показанную реализацию?

producer 2>&1 | consumer

Печатаются plain=0 и strict=1: успешная последняя команда маскирует предыдущий отказ только без pipefail. При большом числе совпадений grep может получить SIGPIPE после завершения head, и pipefail превратит ожидаемое короткое замыкание в ошибку сценария. Явное 2>&1 перед каналом объединяет диагностику с данными, поэтому consumer должен уметь различать их или такое объединение следует избегать. Когда нужен первый результат, встроенное ограничение grep -m1 избегает лишнего процесса head и неоднозначного SIGPIPE. grep получает только ok через stdout и печатает его; bad остаётся в stderr терминала.

Вопрос 10 из 20

Разберите код без пробного запуска; его тема — «Статусы команд конвейера». Какой ответ учитывает и полезный эффект, и остающееся ограничение кода?

pipeline
statuses=("${PIPESTATUS[@]}")
for s in "${statuses[@]}"; do ((s==0)) || exit "$s"; done

Сохранённый массив содержит 1 0 1; копирование выполнено сразу, прежде чем другой вызов изменил PIPESTATUS. Когда нужен первый результат, встроенное ограничение grep -m1 избегает лишнего процесса head и неоднозначного SIGPIPE. wc печатает 2, и файл также содержит две строки: tee пропустил данные дальше и сохранил копию. Статусы нужно скопировать немедленно и затем анализировать сохранённый массив, иначе диагностика уничтожит данные. Печатаются plain=0 и strict=1: успешная последняя команда маскирует предыдущий отказ только без pipefail.

Вопрос 11 из 20

Разберите код без пробного запуска; его тема — «Разветвление потока через tee». Код предлагают как альтернативу. Какова его точная техническая оценка?

set -o pipefail
generate | tee "$artifact" | checksum

Сохранённый массив содержит 1 0 1; копирование выполнено сразу, прежде чем другой вызов изменил PIPESTATUS. grep получает только ok через stdout и печатает его; bad остаётся в stderr терминала. Печатаются plain=0 и strict=1: успешная последняя команда маскирует предыдущий отказ только без pipefail. pipefail делает ненулевой статус tee видимым всему конвейеру, хотя для точной диагностики всё равно полезно сохранить PIPESTATUS. wc печатает 2, и файл также содержит две строки: tee пропустил данные дальше и сохранил копию.

Вопрос 12 из 20

Разберите код без пробного запуска; его тема — «Ошибки в цепочке». Что является главным свойством этого варианта?

if grep -m1 pattern file >result; then
  use result
fi

Печатаются plain=0 и strict=1: успешная последняя команда маскирует предыдущий отказ только без pipefail. Если запись tee в artifact.bin не удалась, checksum всё ещё может завершиться успешно; без pipefail отказ промежуточной команды легко пропустить. После получения одной строки head закрывает канал, и producer может завершиться по SIGPIPE; это нормальное короткое замыкание, а не обязательно дефект producer. Когда нужен первый результат, встроенное ограничение grep -m1 избегает лишнего процесса head и неоднозначного SIGPIPE. grep получает только ok через stdout и печатает его; bad остаётся в stderr терминала.

Вопрос 13 из 20

При переносе решения в автоматизацию проверяют аспект «Канал между процессами». На какой границе эта техника перестаёт быть достаточной сама по себе?

Каждый элемент многоступенчатого конвейера обычно выполняется в отдельном процессе оболочки; изменения переменных не следует использовать как канал результата. tee -a добавляет данные, но несколько процессов, одновременно пишущих большие записи, не получают гарантии логической атомарности строк. pipefail повышает наблюдаемость отказов, но требует разбирать конвейеры, где раннее завершение потребителя является нормальной частью алгоритма. PIPESTATUS относится даже к конвейеру из одной команды; он не заменяет $? для простых случаев, но полезен при разборе цепочки. Каждый элемент многоступенчатого конвейера обычно не выполняется в отдельном процессе оболочки; изменения переменных не следует использовать как канал результата.

Вопрос 14 из 20

При переносе решения в автоматизацию проверяют аспект «Статусы команд конвейера». Где заканчивается защита, которую даёт рассматриваемая конструкция?

tee -a добавляет данные, но несколько процессов, одновременно пишущих большие записи, не получают гарантии логической атомарности строк. pipefail повышает наблюдаемость отказов, но требует разбирать конвейеры, где раннее завершение потребителя является нормальной частью алгоритма. Каждый элемент многоступенчатого конвейера обычно выполняется в отдельном процессе оболочки; изменения переменных не следует использовать как канал результата. PIPESTATUS относится даже к конвейеру из одной команды; он не заменяет $? для простых случаев, но полезен при разборе цепочки. Сохранённый массив содержит 1 0 1; копирование выполнено сразу, прежде чем другой вызов изменил PIPESTATUS.

Вопрос 15 из 20

При переносе решения в автоматизацию проверяют аспект «Разветвление потока через tee». Что способно нарушить ожидаемый результат, хотя основной фрагмент написан корректно?

tee -a не добавляет данные, но несколько процессов, одновременно пишущих большие записи, не получают гарантии логической атомарности строк. PIPESTATUS относится даже к конвейеру из одной команды; он не заменяет $? для простых случаев, но полезен при разборе цепочки. pipefail повышает наблюдаемость отказов, но требует разбирать конвейеры, где раннее завершение потребителя является нормальной частью алгоритма. Каждый элемент многоступенчатого конвейера обычно выполняется в отдельном процессе оболочки; изменения переменных не следует использовать как канал результата. tee -a добавляет данные, но несколько процессов, одновременно пишущих большие записи, не получают гарантии логической атомарности строк.

Вопрос 16 из 20

При переносе решения в автоматизацию проверяют аспект «Ошибки в цепочке». Какой эксплуатационный компромисс здесь нельзя скрывать за успешным кодом возврата?

PIPESTATUS относится даже к конвейеру из одной команды; он не заменяет $? для простых случаев, но полезен при разборе цепочки. Каждый элемент многоступенчатого конвейера обычно выполняется в отдельном процессе оболочки; изменения переменных не следует использовать как канал результата. pipefail повышает наблюдаемость отказов, но требует разбирать конвейеры, где раннее завершение потребителя является нормальной частью алгоритма. tee -a добавляет данные, но несколько процессов, одновременно пишущих большие записи, не получают гарантии логической атомарности строк. pipefail повышает наблюдаемость отказов, но требует разбирать конвейеры, где раннее завершение потребителя не является нормальной частью алгоритма.

Вопрос 17 из 20

Разработчики спорят о границах механизма «Канал между процессами». Какое утверждение точнее всего описывает контракт рассматриваемого механизма?

tee копирует stdin одновременно в stdout и файл; код всего конвейера без pipefail обычно определяется последней командой. Конвейер соединяет stderr предыдущей команды со stdin следующей; stderr не попадает в канал без отдельного перенаправления. Без pipefail код конвейера равен коду последней команды; с pipefail — коду крайней справа неуспешной команды. Массив PIPESTATUS хранит коды всех элементов последнего foreground-конвейера, но следующая простая команда перезаписывает его. Конвейер соединяет stdout предыдущей команды со stdin следующей; stderr не попадает в канал без отдельного перенаправления.

Вопрос 18 из 20

Разработчики спорят о границах механизма «Статусы команд конвейера». Какое правило позволяет правильно разобрать эту тему до запуска кода?

Без pipefail код конвейера равен коду последней команды; с pipefail — коду крайней справа неуспешной команды. tee копирует stdin одновременно в stdout и файл; код всего конвейера без pipefail обычно определяется последней командой. Массив PIPESTATUS хранит коды всех элементов последнего foreground-конвейера, но следующая простая команда дописывает его. Конвейер соединяет stdout предыдущей команды со stdin следующей; stderr не попадает в канал без отдельного перенаправления. Массив PIPESTATUS хранит коды всех элементов последнего foreground-конвейера, но следующая простая команда перезаписывает его.

Вопрос 19 из 20

Разработчики спорят о границах механизма «Разветвление потока через tee». Какое свойство механизма нельзя подменять удачным примером запуска?

Без pipefail код конвейера равен коду последней команды; с pipefail — коду крайней справа неуспешной команды. Конвейер соединяет stdout предыдущей команды со stdin следующей; stderr не попадает в канал без отдельного перенаправления. Массив PIPESTATUS хранит коды всех элементов последнего foreground-конвейера, но следующая простая команда перезаписывает его. tee копирует stdin одновременно в stderr и файл; код всего конвейера без pipefail обычно определяется последней командой. tee копирует stdin одновременно в stdout и файл; код всего конвейера без pipefail обычно определяется последней командой.

Вопрос 20 из 20

Разработчики спорят о границах механизма «Ошибки в цепочке». Какая формулировка связывает частные примеры одним проверяемым правилом?

tee копирует stdin одновременно в stdout и файл; код всего конвейера без pipefail обычно определяется последней командой. Конвейер соединяет stdout предыдущей команды со stdin следующей; stderr не попадает в канал без отдельного перенаправления. Без pipefail код конвейера равен коду первой команды; с pipefail — коду крайней справа неуспешной команды. Без pipefail код конвейера равен коду последней команды; с pipefail — коду крайней справа неуспешной команды. Массив PIPESTATUS хранит коды всех элементов последнего foreground-конвейера, но следующая простая команда перезаписывает его.