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