Условия test и [[ ]] — бесплатный тест онлайн

Вопрос 1 из 20

В служебном сценарии найден следующий фрагмент по теме «Проверка файлов». Какое описание не приписывает фрагменту лишних гарантий?

tmp=$(mktemp -d)
ln -s missing "$tmp/link"
[[ -e $tmp/link ]] && echo e || echo no-e
[[ -L $tmp/link ]] && echo L || echo no-L

Для битой ссылки -e ложно, а -L истинно, поэтому выводятся no-e и L. Пустая строка не является допустимым целым для test и вызывает диагностическое сообщение; сначала нужно проверить формат значения. Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less. Без условной связки с printf сообщение печатается независимо от результата проверки; сам [[ ... ]] лишь устанавливает код завершения. Выводятся B и C: во второй строке C запускается из-за ошибки второй команды, хотя первая была успешна.

Вопрос 2 из 20

В служебном сценарии найден следующий фрагмент по теме «Сравнение строк». Не предполагая намерение автора, что можно утверждать об этой конструкции?

value=report.log
[[ $value == *.log ]] && echo pattern
[[ $value == '*.log' ]] && echo literal || echo no-literal

Пустая строка не является допустимым целым для test и вызывает диагностическое сообщение; сначала нужно проверить формат значения. После некавыченной подстановки test получает лишний аргумент и сообщает ошибку; в [ ... ] переменные со строками нужно заключать в кавычки. Сначала печатается pattern, затем no-literal: кавычки отключают шаблонное значение звёздочки. Без условной связки с printf сообщение печатается независимо от результата проверки; сам [[ ... ]] лишь устанавливает код завершения. Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less.

Вопрос 3 из 20

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

x=08
y=10
if (( 10#$x < 10#$y )); then echo less; fi

Явный if сохраняет смысл: успех наступает только если обе команды успешны, а ошибка command_b не маскируется веткой ||. После некавыченной подстановки test получает лишний аргумент и сообщает ошибку; в [ ... ] переменные со строками нужно заключать в кавычки. Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less. Пустая строка не является допустимым целым для test и вызывает диагностическое сообщение; сначала нужно проверить формат значения. Без условной связки с printf сообщение печатается независимо от результата проверки; сам [[ ... ]] лишь устанавливает код завершения.

Вопрос 4 из 20

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

false && echo A || echo B
true && false || echo C

Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less. Выводятся B и C: во второй строке C запускается из-за ошибки второй команды, хотя первая была успешна. После некавыченной подстановки test получает лишний аргумент и сообщает ошибку; в [ ... ] переменные со строками нужно заключать в кавычки. Двоичные -a и -o внутри test неоднозначны и устарели для сложных выражений; лучше соединить отдельные проверки через && или использовать [[ ... ]]. Сначала печатается pattern, затем no-literal: кавычки отключают шаблонное значение звёздочки.

Вопрос 5 из 20

При проверке темы «Проверка файлов» в тесте «Условия test и [[ ]]» нужно оценить именно этот вариант. Что важно заметить в этом фрагменте до его включения в автоматизацию?

[[ -f $path && -r $path ]]
printf 'ok\n'

Проверка -w полезна, но между ней и записью возможна гонка; сама операция создания должна корректно обрабатывать отказ. Без условной связки с printf сообщение печатается независимо от результата проверки; сам [[ ... ]] лишь устанавливает код завершения. Пустая строка не является допустимым целым для test и вызывает диагностическое сообщение; сначала нужно проверить формат значения. Двоичные -a и -o внутри test неоднозначны и устарели для сложных выражений; лучше соединить отдельные проверки через && или использовать [[ ... ]]. После некавыченной подстановки test получает лишний аргумент и сообщает ошибку; в [ ... ] переменные со строками нужно заключать в кавычки.

Вопрос 6 из 20

При проверке темы «Сравнение строк» в тесте «Условия test и [[ ]]» нужно оценить именно этот вариант. Что действительно гарантирует или, наоборот, не гарантирует эта конструкция?

a='x y'
[ $a = 'x y' ]

Внутри [[ ... ]] логические связки читаются однозначно и не требуют запуска внешних [; это безопаснее цепочки нескольких test. После некавыченной подстановки test получает лишний аргумент и сообщает ошибку; в [ ... ] переменные со строками нужно заключать в кавычки. Для битой ссылки -e ложно, а -L истинно, поэтому выводятся no-e и L. Без условной связки с printf сообщение печатается независимо от результата проверки; сам [[ ... ]] лишь устанавливает код завершения. Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less.

Вопрос 7 из 20

При проверке темы «Числовые условия» в тесте «Условия test и [[ ]]» нужно оценить именно этот вариант. Фрагмент запускают как часть служебного сценария. Как его следует оценить?

n=
[ "$n" -gt 0 ]

Сначала проверяют десятичную запись, затем выполняют арифметическое сравнение; это отделяет ошибочный ввод от значения ноль. Выводятся B и C: во второй строке C запускается из-за ошибки второй команды, хотя первая была успешна. Явный if сохраняет смысл: успех наступает только если обе команды успешны, а ошибка command_b не маскируется веткой ||. Без условной связки с printf сообщение печатается независимо от результата проверки; сам [[ ... ]] лишь устанавливает код завершения. Пустая строка не является допустимым целым для test и вызывает диагностическое сообщение; сначала нужно проверить формат значения.

Вопрос 8 из 20

При проверке темы «Логические связки» в тесте «Условия test и [[ ]]» нужно оценить именно этот вариант. Какой вывод наиболее точно привязан к показанной реализации?

[ -f "$file" -a -r "$file" ]

Явный if сохраняет смысл: успех наступает только если обе команды успешны, а ошибка command_b не маскируется веткой ||. Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less. Двоичные -a и -o внутри test неоднозначны и устарели для сложных выражений; лучше соединить отдельные проверки через && или использовать [[ ... ]]. Сначала печатается pattern, затем no-literal: кавычки отключают шаблонное значение звёздочки. Проверка -w полезна, но между ней и записью возможна гонка; сама операция создания должна корректно обрабатывать отказ.

Вопрос 9 из 20

В тесте «Условия test и [[ ]]» показан фрагмент из блока «Проверка файлов». Код предлагают как альтернативу. Какова его точная техническая оценка?

if [[ -d $dir && -w $dir ]]; then
  create_file "$dir"
fi

Проверка -w полезна, но между ней и записью возможна гонка; сама операция создания должна корректно обрабатывать отказ. Выводятся B и C: во второй строке C запускается из-за ошибки второй команды, хотя первая была успешна. Для битой ссылки -e ложно, а -L истинно, поэтому выводятся no-e и L. Двоичные -a и -o внутри test неоднозначны и устарели для сложных выражений; лучше соединить отдельные проверки через && или использовать [[ ... ]]. Явный if сохраняет смысл: успех наступает только если обе команды успешны, а ошибка command_b не маскируется веткой ||.

Вопрос 10 из 20

В тесте «Условия test и [[ ]]» показан фрагмент из блока «Сравнение строк». Что является главным свойством этого варианта?

if [[ $answer == yes || $answer == y ]]; then
  accept
fi

Выводятся B и C: во второй строке C запускается из-за ошибки второй команды, хотя первая была успешна. Двоичные -a и -o внутри test неоднозначны и устарели для сложных выражений; лучше соединить отдельные проверки через && или использовать [[ ... ]]. Внутри [[ ... ]] логические связки читаются однозначно и не требуют запуска внешних [; это безопаснее цепочки нескольких test. Сначала печатается pattern, затем no-literal: кавычки отключают шаблонное значение звёздочки. Явный if сохраняет смысл: успех наступает только если обе команды успешны, а ошибка command_b не маскируется веткой ||.

Вопрос 11 из 20

В тесте «Условия test и [[ ]]» показан фрагмент из блока «Числовые условия». Как следует оценить конструкцию, не считая её автоматически исправлением?

[[ $n =~ ^[0-9]+$ ]] && (( n > 0 ))

Сначала печатается pattern, затем no-literal: кавычки отключают шаблонное значение звёздочки. Без условной связки с printf сообщение печатается независимо от результата проверки; сам [[ ... ]] лишь устанавливает код завершения. Внутри [[ ... ]] логические связки читаются однозначно и не требуют запуска внешних [; это безопаснее цепочки нескольких test. Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less. Сначала проверяют десятичную запись, затем выполняют арифметическое сравнение; это отделяет ошибочный ввод от значения ноль.

Вопрос 12 из 20

В тесте «Условия test и [[ ]]» показан фрагмент из блока «Логические связки». Какое суждение правильно описывает показанную реализацию?

if command_a && command_b; then
  success
else
  failure
fi

Пустая строка не является допустимым целым для test и вызывает диагностическое сообщение; сначала нужно проверить формат значения. Сначала проверяют десятичную запись, затем выполняют арифметическое сравнение; это отделяет ошибочный ввод от значения ноль. Выводятся B и C: во второй строке C запускается из-за ошибки второй команды, хотя первая была успешна. Явный if сохраняет смысл: успех наступает только если обе команды успешны, а ошибка command_b не маскируется веткой ||. Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less.

Вопрос 13 из 20

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

Арифметический контекст допускает имена переменных и выражения, поэтому недоверенную строку нельзя без проверки подставлять как формулу. set -e имеет исключения внутри условий, списков &&/|| и других контекстов, поэтому логика обработки ошибок не должна строиться на интуитивном «любая ошибка остановит скрипт». -t fd проверяет, связан ли файловый дескриптор с терминалом; это надёжнее, чем угадывать интерактивность по наличию переменных окружения. -t fd не проверяет, связан ли файловый дескриптор с терминалом; это надёжнее, чем угадывать интерактивность по наличию переменных окружения. Операторы < и > внутри [[ ... ]] выполняют лексикографическое сравнение с учётом локали; для чисел применяют -lt/-gt или арифметический контекст.

Вопрос 14 из 20

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

Операторы < и > внутри [[ ... ]] выполняют лексикографическое сравнение с учётом локали; для чисел применяют -lt/-gt или арифметический контекст. set -e имеет исключения внутри условий, списков &&/|| и других контекстов, поэтому логика обработки ошибок не должна строиться на интуитивном «любая ошибка остановит скрипт». -t fd проверяет, связан ли файловый дескриптор с терминалом; это надёжнее, чем угадывать интерактивность по наличию переменных окружения. Арифметический контекст допускает имена переменных и выражения, поэтому недоверенную строку нельзя без проверки подставлять как формулу. Операторы < и > внутри [[ ... ]] выполняют числовое сравнение с учётом локали; для чисел применяют -lt/-gt или арифметический контекст.

Вопрос 15 из 20

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

set -e имеет исключения внутри условий, списков &&/|| и других контекстов, поэтому логика обработки ошибок не должна строиться на интуитивном «любая ошибка остановит скрипт». Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less. -t fd проверяет, связан ли файловый дескриптор с терминалом; это надёжнее, чем угадывать интерактивность по наличию переменных окружения. Операторы < и > внутри [[ ... ]] выполняют лексикографическое сравнение с учётом локали; для чисел применяют -lt/-gt или арифметический контекст. Арифметический контекст допускает имена переменных и выражения, поэтому недоверенную строку нельзя без проверки подставлять как формулу.

Вопрос 16 из 20

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

set -e имеет исключения внутри условий, списков &&/|| и других контекстов, поэтому логика обработки ошибок не должна строиться на интуитивном «любая ошибка остановит скрипт». Операторы < и > внутри [[ ... ]] выполняют лексикографическое сравнение с учётом локали; для чисел применяют -lt/-gt или арифметический контекст. Арифметический контекст допускает имена переменных и выражения, поэтому недоверенную строку нельзя без проверки подставлять как формулу. set -e имеет исключения внутри условий, списков ||/|| и других контекстов, поэтому логика обработки ошибок не должна строиться на интуитивном «любая ошибка остановит скрипт». -t fd проверяет, связан ли файловый дескриптор с терминалом; это надёжнее, чем угадывать интерактивность по наличию переменных окружения.

Вопрос 17 из 20

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

Команды && и || связывают коды завершения команд, но цепочка a && b || c не является полным аналогом if, если b может завершиться неуспешно. В [[ ... ]] правая часть == без кавычек трактуется как шаблон, а заключённая в кавычки — как буквальная строка. В [ ... ] числовые сравнения выполняют -eq, -ne, -lt, -le, -gt, -ge; символы < и > там относятся к синтаксису оболочки. Операторы -e, -f, -d, -L и -s проверяют разные свойства; существующая символическая ссылка с отсутствующей целью требует отдельной проверки -L. Операторы -e, -f, -d, -L и -s проверяют разные свойства; существующая символическая ссылка с отсутствующей целью не требует отдельной проверки -L.

Вопрос 18 из 20

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

В [[ ... ]] правая часть == без кавычек трактуется как шаблон, а заключённая в кавычки — как буквальная строка. Команды && и || связывают коды завершения команд, но цепочка a && b || c не является полным аналогом if, если b может завершиться неуспешно. Операторы -e, -f, -d, -L и -s проверяют разные свойства; существующая символическая ссылка с отсутствующей целью требует отдельной проверки -L. В [ ... ] числовые сравнения выполняют -eq, -ne, -lt, -le, -gt, -ge; символы < и > там относятся к синтаксису оболочки. В [[ ... ]] правая часть == без кавычек трактуется как буквальная строка, а заключённая в кавычки — как буквальная строка.

Вопрос 19 из 20

Для темы «Числовые условия» нужно отделить свойство механизма от удачного примера. Что в этой теме является свойством языка, а не случайностью конкретного запуска?

Команды && и || связывают коды завершения команд, но цепочка a && b || c не является полным аналогом if, если b может завершиться неуспешно. Префикс 10# заставляет арифметический контекст читать оба значения как десятичные, поэтому печатается less. В [[ ... ]] правая часть == без кавычек трактуется как шаблон, а заключённая в кавычки — как буквальная строка. В [ ... ] числовые сравнения выполняют -eq, -ne, -lt, -le, -gt, -ge; символы < и > там относятся к синтаксису оболочки. Операторы -e, -f, -d, -L и -s проверяют разные свойства; существующая символическая ссылка с отсутствующей целью требует отдельной проверки -L.

Вопрос 20 из 20

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

В [[ ... ]] правая часть == без кавычек трактуется как шаблон, а заключённая в кавычки — как буквальная строка. В [ ... ] числовые сравнения выполняют -eq, -ne, -lt, -le, -gt, -ge; символы < и > там относятся к синтаксису оболочки. Операторы -e, -f, -d, -L и -s проверяют разные свойства; существующая символическая ссылка с отсутствующей целью требует отдельной проверки -L. Команды && и || связывают коды завершения команд, но цепочка a && b || c не является полным аналогом if, если b может завершиться неуспешно. Команды && и || связывают коды завершения команд, но цепочка a && b || c является полным аналогом if, если b может завершиться неуспешно.