errexit を修正するシェル (`set -e`) を作成しようとした人はいますか?

Question 1

のPOSIX標準（参照-e) は、シェルオプションに関する Bash マニュアルよりも明確ですerrexit。

このオプションがオンの場合、コマンドが失敗すると (シェルエラーの結果に記載されているいずれかの理由により、または 0 より大きい終了ステータスを返すことにより)、シェルは、引数なしで exit 特殊組み込みユーティリティを実行した場合と同様に、直ちに終了します。ただし、次の例外があります。

複数コマンドのパイプライン内の個々のコマンドが失敗しても、シェルは終了しません。パイプライン自体の失敗のみが考慮されます。

while、until、if、またはelifの予約語に続く複合リスト、!の予約語で始まるパイプライン、または最後のもの以外のAND-ORリストのコマンドを実行する場合、-e設定は無視されます。

サブシェルコマンド以外の複合コマンドの終了ステータスが -e が無視されている間に失敗の結果であった場合、 -e はこのコマンドには適用されません。

この要件は、シェル環境と各サブシェル環境に個別に適用されます。たとえば、次のようになります。

set -e; (false; echo one) | cat; echo two

false コマンドにより、サブシェルは echo one を実行せずに終了します。ただし、パイプライン (false; echo one) | cat の終了ステータスが 0 であるため、echo two が実行されます。

明らかに、サンプルコードは次の疑似コードと同等です。

( LIST; ) && COMMAND || COMMAND

終了ステータスリスト ゼロになるのは、次の理由による:

シェルerrexitオプションは無視されます。
戻りステータスは、リスト、ここtrue。

したがって、AND リストの 2 番目の部分が実行されますecho "OK"。

Answer

のPOSIX標準（参照-e) は、シェルオプションに関する Bash マニュアルよりも明確ですerrexit。

このオプションがオンの場合、コマンドが失敗すると (シェルエラーの結果に記載されているいずれかの理由により、または 0 より大きい終了ステータスを返すことにより)、シェルは、引数なしで exit 特殊組み込みユーティリティを実行した場合と同様に、直ちに終了します。ただし、次の例外があります。

複数コマンドのパイプライン内の個々のコマンドが失敗しても、シェルは終了しません。パイプライン自体の失敗のみが考慮されます。

while、until、if、またはelifの予約語に続く複合リスト、!の予約語で始まるパイプライン、または最後のもの以外のAND-ORリストのコマンドを実行する場合、-e設定は無視されます。

サブシェルコマンド以外の複合コマンドの終了ステータスが -e が無視されている間に失敗の結果であった場合、 -e はこのコマンドには適用されません。

この要件は、シェル環境と各サブシェル環境に個別に適用されます。たとえば、次のようになります。

set -e; (false; echo one) | cat; echo two

false コマンドにより、サブシェルは echo one を実行せずに終了します。ただし、パイプライン (false; echo one) | cat の終了ステータスが 0 であるため、echo two が実行されます。

明らかに、サンプルコードは次の疑似コードと同等です。

( LIST; ) && COMMAND || COMMAND

終了ステータスリスト ゼロになるのは、次の理由による:

シェルerrexitオプションは無視されます。
戻りステータスは、リスト、ここtrue。

したがって、AND リストの 2 番目の部分が実行されますecho "OK"。

Question 2

「誰か ... を書こうとした人はいますか」という質問への回答ではありませんが、どのように書けばよいかについての考えです。フィードバックを提供できる人がいるかどうか知りたいです。

現在のスクリプトソリューション (Python、JavaScript、古い Perl など) の一般的なアプローチは、try ... catch ブロックを使用することです。想定される動作は、エラーが発生すると例外がトリガーされることです。この動作は、エラーが $? でキャプチャされる *sh の動作と競合します。明らかに、'-e' は、ほとんどの開発者が期待するとおりに動作するように正しく動作しませんでした。これはすでに詳細に文書化されているため、ここで詳しく説明する必要はありません。

2 つの可能なアプローチ:

より良いを作成しますset -e。たとえば、set -ocatcherrより優れたエラー処理などです。
try { list ; }最新のスクリプトソリューションに従って新しいコマンドを追加します

'-ofailerr` は次のように定義できます。

制御フロー (if/while/until) 外でコマンドが失敗した場合、現在実行中のコンテキストは 1 を返す必要があります (または、これが最上位ブロックの場合は終了します)。この変更により、開発者は、失敗したコマンド、または無視できるエラーが明示的にマークされたコマンドに対してエラー処理を提供することが事実上強制されます。
単純なスクリプトで機能し、実際には、未処理のエラーが発生すると中止します。

アプローチtry { list ; }は似ていますが、構文が異なります

例：

function foo {
    cat $* > a.txt
    wc -l a.txt
}

set -oerrfail
foo /non/existing/file    # Will  fail, without executing the "wc -l"

if foo /non/existing/file ; then
   ...
else
   # This is the "catch" block
fi

try ブロックの場合:

try {
    foo /non/existing/file
    ...
} || { catch-block }

事実上、tryは「set -oerrofail」と同等であり、コマンドリストを「if ! { ... } ; then { catch-block }」の下で実行します。

Answer