なぜ 'grep -L x <

なぜ 'grep -L x <</dev/null` は `grep -L x << の場合でも 0 を返します。

私はGNU grep 3.3-1(Debian Buster の現在のバージョン)。

からman grep

終了ステータス

通常、終了状態は、行が選択されている場合は0、行が選択されていない場合は1、エラーが発生した場合は2です。ただし、-qまたはを使用して行を選択すると、--quietエラー--silentが発生しても終了ステータスは0です。

これは以下に関連しています。POSIX。 (-Lここでは指定していません。)

最新バージョンの完全なドキュメントそして最新コミットのドキュメント-L()の--files-without-match詳細はありません。

grep -L x <<<x(in bash)コード1で終了します。これがドキュメントと一致するかどうかはわかりませんが、(ここで選択した行は正確には何ですか?)、少なくとも説明可能です。入力ファイルがありませんx

grep -Lq x <<<xそしてgrep -L x <<<x >/dev/null両方ともコード0で終了します。さて、-q理解するのは少し簡単ですが、stdoutリダイレクトが終了コードに影響するのはなぜですか?したがって、出力を抑制しながら元の終了コード動作を得るには、(set -o pipefail; /bin/grep -L x <<<x | cat >/dev/null)同様のハッキングが必要です。なぜそんなことですか?

GNU grepは非常に広く使用されているため、これがバグかどうかはわかりませんgrep。何か落ちた可能性が高いです。あるいは、終了コードが-L頼る価値がないものかもしれません。このようなテスト実行とソースコードを使用して現在のバージョンの動作を理解できますが、この動作は現在のドキュメントと一致しないため、後で変更される可能性があります。どう思いますか?

(ちなみに、最新のコミットでテスト-L2以外の終了コード(in)と(in)のin-eq-out-infloopような極端な場合以外はテストがないようです。 )-f /dev/nullskip-read

ベストアンサー1

これは間違い、これはGNU 3.4grepで修正済み:

標準出力が/ dev / nullの場合、 "grep -L"の終了ステータスは正しくありません。

[Grep 3.2で導入されたバグ#37716]

これは関連コミットです

おすすめ記事