タグ付けされた質問 「exit-status」

このタグは、質問がコマンドの終了ステータス(戻りコード)の決定または利用に関係している場合に使用します。一般的な構文には$?変数と&&および|| シンボル。

2
割り当ては、コマンド置換がある場合を除いて、終了ステータスを持つコマンドに似ていますか?
次の例とそれらのPOSIXシェルでの出力を参照してください。 false;echo $?またはfalse || echo 1:1 false;foo="bar";echo $?またはfoo="bar" && echo 0:0 foo=$(false);echo $?またはfoo=$(false) || echo 1:1 foo=$(true);echo $?またはfoo=$(true) && echo 0:0 /programming/6834487/what-is-the-variable-in-shell-scriptingの最高投票の回答で述べたように: $? 最後に実行されたコマンドの戻り値を見つけるために使用されます。 これはおそらくこの場合少し誤解を招く可能性があるので、そのスレッドからの投稿でも引用されているPOSIX定義を取得しましょう。 ?最新のパイプラインの10進数の終了ステータスに展開します(パイプラインを参照)。 したがって、割り当て自体はゼロの終了値を持つコマンド(またはパイプラインパーツ)としてカウントされているように見えますが、割り当ての右側の前に適用されます(たとえば、ここでの例ではコマンド置換呼び出し)。 この振る舞いが実用的な見地からどのように意味を成すかはわかりますが、割り当て自体がその順序でカウントされることは、私には幾分珍しいようです。多分それが私にとって奇妙な理由をより明確にするために、割り当てが関数であったと仮定しましょう: ASSIGNMENT( VARIABLE, VALUE ) そしてfoo="bar"だろう ASSIGNMENT( "foo", "bar" ) のfoo=$(false)ようなものになります ASSIGNMENT( "foo", EXECUTE( "false" ) ) そのことを意味するEXECUTE実行が最初と後にのみ ASSIGNMENT実行されますが、それはまだだEXECUTEここで問題のステータス。 私の評価は正しいですか、それとも何かを誤解/不足していますか?これらは、私がこの振る舞いを「奇妙な」ものと見なす正しい理由ですか?

2
変数割り当ての戻りステータスはどのように決定されますか?
私はこのようなスクリプトの構成を見てきました: if somevar="$(somecommand 2>/dev/null)"; then ... fi これはどこかに文書化されていますか?変数の戻りステータスはどのように決定され、コマンド置換とどのように関連していますか?(たとえば、私は同じ結果を得るでしょうif echo "$(somecommand 2>/dev/null)"; thenか?)

7
時間コマンドと同様に、コマンドのログ終了コード
を使用して time sleep 1 利回り: $ time sleep 1 real 0m1.005s user 0m0.001s sys 0m0.001s 終了コードsleepや実行したいコマンドを出力するために使用できるコマンドはありますか? 好きなもの: $ log-exit-code sleep 1 おそらくこれで十分ですか? sleep 1 && echo "$?"
10 exit  exit-status 

1
「less」をゼロ以外のステータスコードで終了させますか?
次のコマンド構造にしたいと思います。 command && check-status | less && followup-command これにより、ユーザーがと対話してlessいる間、実行が一時停止します。ユーザーは、実行lessを防ぐためにfollowup-command、ゼロ以外のステータスで強制的に終了することができますか? 私は現在使用しています less 458 (POSIX regular expressions)



6
終了コードではなく戻り値に基づいてパイプラインを構築するエレガントな方法?
ステータスコードが役に立たない場合、標準出力からの出力に基づいてパイプラインを構築する方法はありますか? ユースケースではなく、シェルスクリプトの範囲内の質問に答える方がいいと思います。私がやろうとしていることは、国と言語コードに基づいて名前を推測することにより、リポジトリで利用可能な最も具体的なパッケージを見つけることです。 これを例にとると、 $PACKAGE1=hunspell-en-zz $PACKAGE2=hunspell-en 最初の推測はより適切ですが、存在しない可能性があります。この場合、最初のオプション()が存在しないため、hunspell-en($PACKAGE2)を返します。hunspell-en-zz$PACKAGE1 apt-cacheのパイプライン apt-cacheコマンドが実行できる場合は常に、シェルによって終了コード0として定義されるコマンドが成功を返します(のドキュメントからapt-cache) apt-cacheは通常の操作ではゼロを返し、エラーの場合は10進数の100を返します。 これにより、パイプラインでのコマンドの使用がより困難になります。通常、私は404に相当するパッケージ検索でエラーが発生することを期待しています(curlまたはで発生しますwget)。パッケージが存在するかどうかを確認し、存在しない場合は別のパッケージにフォールバックしたい。 最初のコマンドが成功を返すため、これは何も返しません(したがって、||neverのrhs は実行されません)。 apt-cache search hunspell-en-zz || apt-cache search hunspell-en apt-cache search 2つの引数 これは、apt-cacheその引数のANDを取るため、何も返しません。 apt-cache search hunspell-en-zz hunspell-en のドキュメントから apt-cache 別々の引数を使用して、AND結合された複数の検索パターンを指定できます。 したがって、これらの引数の1つが明らかに存在しないため、これは何も返しません。 質問 apt-cacheタスクに戻りコードが役に立たない場合に見られるような規則を処理するためのシェルイディオムは何ですか?そして、成功はSTDOUT上の出力の存在によってのみ決定されますか? に似ている 何も見つからなかったときに検索を失敗させる どちらも同じ問題に起因しています。そこで選択された答えはfind -z、残念なことに、ここで適用できる解決策ではなく、ユースケース固有のものです。ヌル終了を使用せずにイディオムやパイプラインを構築することについての言及はありません(のオプションではありませんapt-cache)

1
ネストされたコマンドの格納されたリターンコードで終了すると、DashとBashで異なるリターンコードが発生するのはなぜですか?
ランニング bash -c 'bash -c "echo test1; exit 1;" &> /tmp/x; buildresult=$?; tail -n 100 /tmp/x; exit $buildresult;' で結果test1コンソールに印刷されてecho $?印刷するには1、コマンドが内部でどのように返す必要がありますので、正確である私の理解でいる[b/d]ash -cのに対し、返さ dash -c 'dash -c "echo test1; exit 1;" &> /tmp/x; buildresult=$?; tail -n 100 /tmp/x; exit $buildresult;' 結果は同じ出力になりますが、0に従って戻りますecho $?。 シェルとポータブルシェルプログラミングの理解を深めるために、この違いを理解したいと思います。 Ubuntu 17.10(Artful Aardvark)でbash4.4.12およびdash0.5.8-2.3ubuntu1 を使用しています。

6
テスト後に最後の終了ステータスを維持する方法
$?テスト後に最後のコマンドの終了ステータス()を変更しないでおくことは可能ですか? 例えば、私はしたいと思います: command -p sudo ... [ $? -ne 1 ] && exit $? 最後exit $?はsudo終了ステータスを返す必要がありますが、代わりに常に0(テストの終了コード)を返します。 一時変数なしでそれを行うことは可能ですか? さらに明確にする別の例: spd-say "$@" [ $? -ne 127 ] && exit $? この場合、最初のコマンドが見つかった場合にのみ終了します(終了コード!= 127)。そして、私は実際のspd-say終了コードで終了したいです(それはそうではないかもしれません 0)。 編集:私は、移植性を高めるためにPOSIX準拠のソリューションを好むことを忘れていました。 同じコマンドの代替手段を提供したいスクリプトでこの構成を使用します。たとえば、私のcrc32スクリプトを参照してください。 一時変数の問題は、他の変数を隠してしまう可能性があり、長い名前を使用しなければならないことを回避することです。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.