回答:
このパターンの理由は、Debianパッケージのメンテナースクリプトはで始まる傾向があるためset -e、コマンド（厳密に言えば、パイプライン、リスト、または複合コマンド）がゼロ以外のステータスで終了するとすぐにシェルが終了するためです。これにより、エラーが累積しないことが保証されます。何か問題が発生するとすぐに、スクリプトが中止されます。
スクリプト内のコマンドの失敗が許可されている場合、追加|| trueすると、結果の複合コマンドが常にステータス0で終了するため、スクリプトは中止されません。たとえば、ディレクトリの削除は致命的なエラーではありません（パッケージの削除を防止します）。だから私たちは使うだろう
rmdir ... || truermdirエラーを無視するように指示するオプションがないためです。
set -eまったく必要なしに|| true、コンテキストを提供することが重要だと思いました。POWERで奇妙なことに気づいたら、バグ（reportbug）を提出することを強くお勧めします！
set -eは「Debian規約」だけでなく、常に使用すべき優れたプログラミングパターンです。見る。例：davidpashley.com/articles/writing-robust-shell-scripts
|| trueset -eを使用するのがコンテキストであり、最も一般的である可能性が高いか この答えにお辞儀をします！文字通り、終了ステータスが無関係であると見なされる場合はいつでも役立ちます（記事リンクが追加するように）、スクリプト制御の一部として終了ステータスを使用していません。ユーティリティ（set -e）が表示されますが、記事に記載されている限り、「作成するすべてのスクリプトにはset -eを先頭に含める必要があります」とは言えません。それはプログラミングのスタイルです。「ALWAYS | Every」には、独自のトラップセットが含まれていALWAYSます。
set -e動作に歴史的な矛盾があります。ターゲットがでbashあり、に住んでいる他の比較的最近のシェルである場合、それは重要ではないかもしれません/bin/shが、古いシェル/システムをサポートしたい場合、状況はより微妙です。
set -e動作を文書化した非常に詳細なページがありますが、このページには、今日では関係のない多くの歴史的/古代のシェルも文書化されています。また、これらの2つのページには、最近のより狭いフォーカス（「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 $?
0
set -eそして|| true効用はその特性と目標プログラマー
git remote remove foo || true git remote add foo http://blah-リモートが存在しない場合、エラーを無視したい。
||:これを記述するためのもう1つの慣用的な方法です（:ビルトインテーブル内の別のエントリを指しますが、Bourneに戻ってもビルトインであることtrueが保証されています。つまり、POSIX shの場合trueも同様にビルトインであることが保証されているため、遠隔から現代にかけての効率よりも簡潔さ）。