В настоящее время я изучаю пакеты Debian и читаю несколько примеров кода. Например, в каждой строке postinstскрипта есть шаблон.
some command || true
another command || trueТак что, если какая-то команда завершится неудачно, строка вернет true, но я не вижу, как это повлияет на вывод программы.
shell-script
error-handling
столяр
источник
источник
||:это еще один идиоматический способ написания этого (:будучи еще одной записью во встроенной таблице, указывающей наtrue- но гарантированно встроенной даже в Борне; при этом для POSIX shtrueтакже гарантированно будет встроенной - так что это больше краткости, чем эффективности в даже отдаленно-современные времена).Ответы:
Причина этого шаблона заключается в том, что сценарии сопровождающего в пакетах Debian, как правило, начинаются с того
set -e, что оболочка завершает работу, как только завершается любая команда (строго говоря, команда pipe, list или составная команда) с ненулевым статусом. Это гарантирует, что ошибки не будут накапливаться: как только что-то пойдет не так, скрипт прерывается.В тех случаях, когда команде в сценарии разрешается сбой, добавление
|| trueгарантирует, что результирующая составная команда всегда завершается с нулевым статусом, поэтому сценарий не прерывается. Например, удаление каталога не должно быть фатальной ошибкой (предотвращение удаления пакета); поэтому мы будем использоватьтак
rmdirкак не имеет возможности сказать ему игнорировать ошибки.источник
set -eнужды|| trueвообще я думал, что важно предоставить контекст. Если вы заметили странные вещи на POWER, я настоятельно рекомендую вам регистрировать ошибки (reportbug)!set -eэто не только «соглашение Debian», но и хороший шаблон программирования, который всегда следует использовать. Видеть. например, davidpashley.com/articles/writing-robust-shell-scripts|| trueset -e является вероятным контекстом и, вероятно, наиболее распространенным. Я преклоняюсь перед этим ответом! Буквально, однако, это полезно в любое время, когда статус выхода считается неактуальным И (как добавляет ссылка на вашу статью) Я не использую статус выхода как часть контроля скрипта. Я вижу утилиту (inset -e), но не буду заходить так далеко, как в статье, и скажу: «Каждый сценарий, который вы пишете, должен включать -e вверху». Это стиль программирования. «ВСЕГДА | Каждый» включает в себя свой собственный набор ловушек - иначе - абсолюты: решения сALWAYSподстановочными знаками в конечном итоге будут иметь обратный эффект, иначе - никаких бесплатных поездок.set -eповедением. Для вас может не иметь значения, если ваши единственные цели - этоbashи другие относительно недавние оболочки, которые живут/bin/sh, но ситуация более нюансирована, если вы хотите поддерживать старые оболочки / системы.set -eповедение различных оболочек Свена Машека , хотя эта страница также документирует множество исторических / древних оболочек, не относящихся к сегодняшнему дню . Есть также эти две страницы с более узким современным фокусом (поиск «set -e»): страница «lintsh» , документация переносимой оболочки autoconf -> Подстраница «Ограничение встроенных функций»Хотя это не влияет на вывод программы, просто запустите ее - она позволяет вызывающей программе действовать так, как будто все в порядке, иначе она влияет на логику будущего.
Перефразировано: маскирует статус ошибки предыдущей команды.
источник
set -eи|| trueполезность будет определяться чертами и целями программист.git remote remove foo || truegit remote add foo http://blah- мы хотим игнорировать ошибку, если пульт не существует.