Строгий режим Bash — бесплатный тест онлайн

Вопрос 1 из 25

На ревью сценария по теме «Остановка при ошибке set -e» встретился этот код. Какое наблюдение выдерживает проверку по аргументам, потокам и коду завершения?

set -e
if false; then echo no; fi
echo alive

false используется как условие if, поэтому errexit не завершает сценарий; печатается alive. Крайняя справа неуспешная команда имеет код 5, поэтому весь конвейер возвращает 5. Поскольку функция вызывается в условном контексте, -e может быть подавлен для команд внутри неё, и echo continued выполнится. Печатается <default>: форма с дефисом безопасно задаёт значение только для неустановленной переменной. Если producer получает SIGPIPE после раннего выхода head, конвейер может стать неуспешным и errexit остановит сценарий до done.

Вопрос 2 из 25

На ревью сценария по теме «Контроль неустановленных переменных set -u» встретился этот код. Что в этом коде произойдёт или останется верным при указанных условиях?

set -u
unset name
printf '<%s>\n' "${name-default}"

Поскольку функция вызывается в условном контексте, -e может быть подавлен для команд внутри неё, и echo continued выполнится. Печатается <default>: форма с дефисом безопасно задаёт значение только для неустановленной переменной. Постинкремент возвращает значение 0 и статус 1, поэтому сценарий завершается раньше вывода, хотя count уже стал 1. Переписывание должно учитывать не только вывод, но и статусы обеих сторон; часто инструмент producer имеет собственный лимит, устраняющий SIGPIPE. Поведение пустых и несуществующих массивов менялось между версиями Bash; прямое раскрытие неинициализированного массива может нарушить сценарий.

Вопрос 3 из 25

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

set -o pipefail
(exit 3) | (exit 5) | true
printf '%s\n' "$?"

Крайняя справа неуспешная команда имеет код 5, поэтому весь конвейер возвращает 5. При отсутствии совпадений grep возвращает 1, и под строгим режимом присваивание может завершить сценарий, хотя «ничего не найдено» было нормальным результатом. Явная инициализация коллекций и значения по умолчанию делают контракт понятным при nounset. Если producer получает SIGPIPE после раннего выхода head, конвейер может стать неуспешным и errexit остановит сценарий до done. Код нужно сохранить прежде, чем арифметическая проверка изменит $?: корректная версия использует отдельную переменную rc сразу после grep.

Вопрос 4 из 25

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

set -euo pipefail
count=0
((count++))
echo "$count"

Постинкремент возвращает значение 0 и статус 1, поэтому сценарий завершается раньше вывода, хотя count уже стал 1. Если producer получает SIGPIPE после раннего выхода head, конвейер может стать неуспешным и errexit остановит сценарий до done. При отсутствии совпадений grep возвращает 1, и под строгим режимом присваивание может завершить сценарий, хотя «ничего не найдено» было нормальным результатом. Переписывание должно учитывать не только вывод, но и статусы обеих сторон; часто инструмент producer имеет собственный лимит, устраняющий SIGPIPE. Сценарий должен сам объявить требуемую оболочку и режим; -E добавляют только при осознанном использовании ERR trap.

Вопрос 5 из 25

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

printf 'bash=%s flags=%s\n' "$BASH_VERSION" "$-" >&2
set -o | grep -E 'errexit|nounset|pipefail' >&2

Код нужно сохранить прежде, чем арифметическая проверка изменит $?: корректная версия использует отдельную переменную rc сразу после grep. SHELLOPTS readonly внутри Bash и может наследовать часть опций через окружение, но полагаться на внешний запуск вместо явной настройки сценария не стоит. Вывод показывает версию, короткие флаги и фактические значения ключевых опций, помогая сравнить окружения. Если producer получает SIGPIPE после раннего выхода head, конвейер может стать неуспешным и errexit остановит сценарий до done. Крайняя справа неуспешная команда имеет код 5, поэтому весь конвейер возвращает 5.

Вопрос 6 из 25

Перед запуском фрагмента из раздела «Остановка при ошибке set -e» нужен точный прогноз. Что следует записать в заключении ревью этого фрагмента?

set -e
f() { false; echo continued; }
if f; then :; fi

Поскольку функция вызывается в условном контексте, -e может быть подавлен для команд внутри неё, и echo continued выполнится. Крайняя справа неуспешная команда имеет код 5, поэтому весь конвейер возвращает 5. Переписывание должно учитывать не только вывод, но и статусы обеих сторон; часто инструмент producer имеет собственный лимит, устраняющий SIGPIPE. Поведение пустых и несуществующих массивов менялось между версиями Bash; прямое раскрытие неинициализированного массива может нарушить сценарий. Критический шаг следует проверять явно и возвращать ошибку, а не надеяться, что глобальный set -e одинаково действует во всех местах вызова.

Вопрос 7 из 25

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

set -u
for x in "$@"; do :; done
printf '%s\n' "${array[@]}"

Поведение пустых и несуществующих массивов менялось между версиями Bash; прямое раскрытие неинициализированного массива может нарушить сценарий. false используется как условие if, поэтому errexit не завершает сценарий; печатается alive. При отсутствии совпадений grep возвращает 1, и под строгим режимом присваивание может завершить сценарий, хотя «ничего не найдено» было нормальным результатом. Если producer получает SIGPIPE после раннего выхода head, конвейер может стать неуспешным и errexit остановит сценарий до done. Явная инициализация коллекций и значения по умолчанию делают контракт понятным при nounset.

Вопрос 8 из 25

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

set -euo pipefail
producer | head -n 1
echo done

Если producer получает SIGPIPE после раннего выхода head, конвейер может стать неуспешным и errexit остановит сценарий до done. Сценарий должен сам объявить требуемую оболочку и режим; -E добавляют только при осознанном использовании ERR trap. Печатается <default>: форма с дефисом безопасно задаёт значение только для неустановленной переменной. Код нужно сохранить прежде, чем арифметическая проверка изменит $?: корректная версия использует отдельную переменную rc сразу после grep. Переписывание должно учитывать не только вывод, но и статусы обеих сторон; часто инструмент producer имеет собственный лимит, устраняющий SIGPIPE.

Вопрос 9 из 25

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

matches=$(grep pattern file)

Поведение пустых и несуществующих массивов менялось между версиями Bash; прямое раскрытие неинициализированного массива может нарушить сценарий. Печатается <default>: форма с дефисом безопасно задаёт значение только для неустановленной переменной. При отсутствии совпадений grep возвращает 1, и под строгим режимом присваивание может завершить сценарий, хотя «ничего не найдено» было нормальным результатом. Код нужно сохранить прежде, чем арифметическая проверка изменит $?: корректная версия использует отдельную переменную rc сразу после grep. SHELLOPTS readonly внутри Bash и может наследовать часть опций через окружение, но полагаться на внешний запуск вместо явной настройки сценария не стоит.

Вопрос 10 из 25

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

SHELLOPTS=errexit:pipefail bash script.sh

Поведение пустых и несуществующих массивов менялось между версиями Bash; прямое раскрытие неинициализированного массива может нарушить сценарий. SHELLOPTS readonly внутри Bash и может наследовать часть опций через окружение, но полагаться на внешний запуск вместо явной настройки сценария не стоит. Печатается <default>: форма с дефисом безопасно задаёт значение только для неустановленной переменной. Сценарий должен сам объявить требуемую оболочку и режим; -E добавляют только при осознанном использовании ERR trap. Явная инициализация коллекций и значения по умолчанию делают контракт понятным при nounset.

Вопрос 11 из 25

Этот участок из темы «Остановка при ошибке set -e» относится к практической части теста «Строгий режим Bash». Какой вывод соответствует именно этой записи, а не общему совету по теме?

f() { critical_step || return; next_step; }

false используется как условие if, поэтому errexit не завершает сценарий; печатается alive. Критический шаг следует проверять явно и возвращать ошибку, а не надеяться, что глобальный set -e одинаково действует во всех местах вызова. Постинкремент возвращает значение 0 и статус 1, поэтому сценарий завершается раньше вывода, хотя count уже стал 1. При отсутствии совпадений grep возвращает 1, и под строгим режимом присваивание может завершить сценарий, хотя «ничего не найдено» было нормальным результатом. Код нужно сохранить прежде, чем арифметическая проверка изменит $?: корректная версия использует отдельную переменную rc сразу после grep.

Вопрос 12 из 25

Этот участок из темы «Контроль неустановленных переменных set -u» относится к практической части теста «Строгий режим Bash». Что можно уверенно сказать об этом решении после пошагового разбора?

declare -a array=()
for x in "${array[@]}"; do :; done

Явная инициализация коллекций и значения по умолчанию делают контракт понятным при nounset. Если producer получает SIGPIPE после раннего выхода head, конвейер может стать неуспешным и errexit остановит сценарий до done. Печатается <default>: форма с дефисом безопасно задаёт значение только для неустановленной переменной. Постинкремент возвращает значение 0 и статус 1, поэтому сценарий завершается раньше вывода, хотя count уже стал 1. false используется как условие if, поэтому errexit не завершает сценарий; печатается alive.

Вопрос 13 из 25

Этот участок из темы «Ошибки в конвейере pipefail» относится к практической части теста «Строгий режим Bash». Какое утверждение относится к приведённому фрагменту без лишних допущений?

first=$(producer | { IFS= read -r line; printf '%s' "$line"; })

false используется как условие if, поэтому errexit не завершает сценарий; печатается alive. Поскольку функция вызывается в условном контексте, -e может быть подавлен для команд внутри неё, и echo continued выполнится. Критический шаг следует проверять явно и возвращать ошибку, а не надеяться, что глобальный set -e одинаково действует во всех местах вызова. Крайняя справа неуспешная команда имеет код 5, поэтому весь конвейер возвращает 5. Переписывание должно учитывать не только вывод, но и статусы обеих сторон; часто инструмент producer имеет собственный лимит, устраняющий SIGPIPE.

Вопрос 14 из 25

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

if matches=$(grep pattern file); then
  :
elif (($? == 1)); then
  matches=
else
  exit $?
fi

false используется как условие if, поэтому errexit не завершает сценарий; печатается alive. Поскольку функция вызывается в условном контексте, -e может быть подавлен для команд внутри неё, и echo continued выполнится. Код нужно сохранить прежде, чем арифметическая проверка изменит $?: корректная версия использует отдельную переменную rc сразу после grep. Критический шаг следует проверять явно и возвращать ошибку, а не надеяться, что глобальный set -e одинаково действует во всех местах вызова. Постинкремент возвращает значение 0 и статус 1, поэтому сценарий завершается раньше вывода, хотя count уже стал 1.

Вопрос 15 из 25

Этот участок из темы «Проверка и диагностика» относится к практической части теста «Строгий режим Bash». Что этот вариант меняет в поведении сценария на самом деле?

#!/usr/bin/env bash
set -Eeuo pipefail

Сценарий должен сам объявить требуемую оболочку и режим; -E добавляют только при осознанном использовании ERR trap. Явная инициализация коллекций и значения по умолчанию делают контракт понятным при nounset. Критический шаг следует проверять явно и возвращать ошибку, а не надеяться, что глобальный set -e одинаково действует во всех местах вызова. Вывод показывает версию, короткие флаги и фактические значения ключевых опций, помогая сравнить окружения. false используется как условие if, поэтому errexit не завершает сценарий; печатается alive.

Вопрос 16 из 25

В документации к сценарию уточняют контракт темы «Остановка при ошибке set -e». Какое ограничение особенно важно учесть перед переносом решения в эксплуатацию?

Поведение -e имеет исторические тонкости между версиями и подоболочками; надёжный скрипт использует его как страховку, а не как единственную модель ошибок. Строгий режим требует тестов на негативные ветви; запуск только на счастливом пути создаёт ложное чувство надёжности. false используется как условие if, поэтому errexit не завершает сценарий; печатается alive. ${!prefix@} и косвенные расширения могут обращаться к динамическим именам; set -u не превращает недоверенное имя в безопасное. pipefail не предоставляет массив кодов и не сообщает, какая команда упала; для расследования нужен PIPESTATUS, сохранённый до следующей команды.

Вопрос 17 из 25

В документации к сценарию уточняют контракт темы «Контроль неустановленных переменных set -u». Какую оговорку стоит вынести в описание эксплуатационного контракта?

Поведение -e имеет исторические тонкости между версиями и подоболочками; надёжный скрипт использует его как страховку, а не как единственную модель ошибок. pipefail не предоставляет массив кодов и не сообщает, какая команда упала; для расследования нужен PIPESTATUS, сохранённый до следующей команды. Трассировка set -x сама может раскрыть секреты; для диагностики строгого режима её включают локально и редактируют чувствительные значения. ${!prefix@} и косвенные расширения могут обращаться к динамическим именам; set -u не превращает недоверенное имя в безопасное. Печатается <default>: форма с дефисом безопасно задаёт значение только для неустановленной переменной.

Вопрос 18 из 25

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

Трассировка set -x сама может раскрыть секреты; для диагностики строгого режима её включают локально и редактируют чувствительные значения. ${!prefix@} и косвенные расширения могут обращаться к динамическим именам; set -u не превращает недоверенное имя в безопасное. Строгий режим требует тестов на негативные ветви; запуск только на счастливом пути создаёт ложное чувство надёжности. Крайняя справа неуспешная команда имеет код 5, поэтому весь конвейер возвращает 5. pipefail не предоставляет массив кодов и не сообщает, какая команда упала; для расследования нужен PIPESTATUS, сохранённый до следующей команды.

Вопрос 19 из 25

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

Трассировка set -x сама может раскрыть секреты; для диагностики строгого режима её включают локально и редактируют чувствительные значения. Строгий режим требует тестов на негативные ветви; запуск только на счастливом пути создаёт ложное чувство надёжности. Строгий режим требует тестов на негативные ветви; запуск только на счастливом пути не создаёт ложное чувство надёжности. pipefail не предоставляет массив кодов и не сообщает, какая команда упала; для расследования нужен PIPESTATUS, сохранённый до следующей команды. ${!prefix@} и косвенные расширения могут обращаться к динамическим именам; set -u не превращает недоверенное имя в безопасное.

Вопрос 20 из 25

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

Трассировка set -x сама может раскрыть секреты; для диагностики строгого режима её включают локально и редактируют чувствительные значения. pipefail не предоставляет массив кодов и не сообщает, какая команда упала; для расследования нужен PIPESTATUS, сохранённый до следующей команды. ${!prefix@} и косвенные расширения могут обращаться к динамическим именам; set -u не превращает недоверенное имя в безопасное. Вывод показывает версию, короткие флаги и фактические значения ключевых опций, помогая сравнить окружения. Строгий режим требует тестов на негативные ветви; запуск только на счастливом пути создаёт ложное чувство надёжности.

Вопрос 21 из 25

При переносе решения в автоматизацию проверяют аспект «Остановка при ошибке set -e». На какую гарантию Bash следует опираться при техническом ревью этого участка?

Для воспроизводимой диагностики полезно фиксировать опции оболочки, версию Bash, команду запуска и минимальный фрагмент, потому что контекст влияет на errexit. errexit не означает «завершиться после любой ненулевой команды»: он подавляется в условиях if/while, частях ||/||, после ! и в других контекстах. errexit не означает «завершиться после любой ненулевой команды»: он подавляется в условиях if/while, частях &&/||, после ! и в других контекстах. pipefail возвращает статус крайней справа неуспешной команды конвейера, а если все успешны — ноль. nounset завершает расширение неустановленной переменной, но формы ${v-}, ${v:-default} и проверки -v позволяют обработать отсутствие явно.

Вопрос 22 из 25

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

pipefail возвращает статус крайней справа неуспешной команды конвейера, а если все успешны — ноль. Комбинация set -euo pipefail полезна, но ломает допустимые случаи вроде grep без совпадений, арифметического нуля и необязательной переменной без явной обработки. nounset завершает расширение неустановленной переменной, но формы ${v-}, ${v:-default} и проверки -v позволяют обработать отсутствие явно. errexit не означает «завершиться после любой ненулевой команды»: он подавляется в условиях if/while, частях &&/||, после ! и в других контекстах. Печатается <default>: форма с дефисом безопасно задаёт значение только для неустановленной переменной.

Вопрос 23 из 25

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

pipefail не возвращает статус крайней справа неуспешной команды конвейера, а если все успешны — ноль. nounset завершает расширение неустановленной переменной, но формы ${v-}, ${v:-default} и проверки -v позволяют обработать отсутствие явно. errexit не означает «завершиться после любой ненулевой команды»: он подавляется в условиях if/while, частях &&/||, после ! и в других контекстах. Комбинация set -euo pipefail полезна, но ломает допустимые случаи вроде grep без совпадений, арифметического нуля и необязательной переменной без явной обработки. pipefail возвращает статус крайней справа неуспешной команды конвейера, а если все успешны — ноль.

Вопрос 24 из 25

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

pipefail возвращает статус крайней справа неуспешной команды конвейера, а если все успешны — ноль. nounset завершает расширение неустановленной переменной, но формы ${v-}, ${v:-default} и проверки -v позволяют обработать отсутствие явно. Для воспроизводимой диагностики полезно фиксировать опции оболочки, версию Bash, команду запуска и минимальный фрагмент, потому что контекст влияет на errexit. Постинкремент возвращает значение 0 и статус 1, поэтому сценарий завершается раньше вывода, хотя count уже стал 1. Комбинация set -euo pipefail полезна, но ломает допустимые случаи вроде grep без совпадений, арифметического нуля и необязательной переменной без явной обработки.

Вопрос 25 из 25

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

Комбинация set -euo pipefail полезна, но ломает допустимые случаи вроде grep без совпадений, арифметического нуля и необязательной переменной без явной обработки. pipefail возвращает статус крайней справа неуспешной команды конвейера, а если все успешны — ноль. Вывод показывает версию, короткие флаги и фактические значения ключевых опций, помогая сравнить окружения. errexit не означает «завершиться после любой ненулевой команды»: он подавляется в условиях if/while, частях &&/||, после ! и в других контекстах. Для воспроизводимой диагностики полезно фиксировать опции оболочки, версию Bash, команду запуска и минимальный фрагмент, потому что контекст влияет на errexit.