GREPが「0.jpg」という単一のファイルの代わりにバイナリファイルを出力するのはなぜですか?

GREPが「0.jpg」という単一のファイルの代わりにバイナリファイルを出力するのはなぜですか?

私はBASHが好きですが、GREPに苦労しています。

私の目標は簡単です。デスクトップファイルのGREP「0.jpg」です。

私のBASHコード:

$ pwd
/Users/jennalusche/Desktop
$ grep "0" *.jpg

予想される結果:

0.jpg

実際の結果:

Binary file IMG_2125.jpg matches
Binary file the-letter-just-j-bw-vectorized-v2.jpg matches

オペレーティングシステム

Mac OS Xヨセミテ

私の質問

GREP "0" *.jpgが"0.jpg"という単一のファイルの代わりにバイナリファイルを表示するのはなぜですか?

私のデバッグ原則

私はこれらのファイルが現れる理由がそれらがすべて「バイナリ」だからだと仮定します。 "バイナリファイル" = 0と1でエンコードされたファイル。したがって、表示されている両方のファイルは0に変換され、PWD内の他のすべてのファイルは1に変換されます。

私の当然の質問 -

出力が0.jpgではないのはなぜですか?

理由の確認

両方の出力ファイル(バイナリ形式)は0で、PWDの他のすべてのファイルは1であると仮定します。この仮定は正しいですか?

ウサギの洞窟に落ちる——

生成されたファイルがすべてゼロであるのはなぜですか?私は意図的にこれらのファイルを特別な方法でエンコードしませんでした。ファイルが1エンコードされたGREP検索に表示されませんか?では、なぜそうなのでしょうか?

ウサギの洞窟の中に深く転がりながら— グレブ。 SED。 AWK。 LS猫。エコ。探す。

明らかに、これらのユーティリティの機能には重複する部分がたくさんあります。

活用面で一番好きな組み合わせは何ですか?

ベストアンサー1

grep実用的な事項ファイル内を見てください正規表現に一致する行です。

あなたが望むのは、0名前が(0)でサフィックスがある現在のディレクトリのファイルを一覧表示することです.jpg

ls -l ./*0*.jpg

または実際には

echo ./*0*.jpg

パターンの最初の部分は*0*ゼロを含むすべての文字列と一致し、パターンの最後の部分は生成されたファイル名を対応するサフィックス.jpgで終わるファイル名に制限します。これは./「このディレクトリにあります」を意味し、ファイル名が(ダッシュ)で始まる場合にのみ実際に必要です-(そうしないと、コマンドラインオプションとして誤って解釈される可能性があります)。

このパターンの拡張は呼び出し前にシェルによって実行されるため、パターンと一致lsするlsファイル名の拡張リストが得られ、一覧表示されます。

ファイル名ワイルドカードパターンは正規表現ではありません。似たようなしてください)。 grep一方、1つ以上の正規表現を使用してファイルの内容を検索します。


見つかった質問に答えるコメントから:「警告」は致命的ではない形式です。診断出力。他のタイプは「エラー」で、通常は致命的です(つまり、プログラムは通常どおり続行できず、エラーメッセージを出力した後に終了します)。

診断メッセージは通常、通常の操作中にコマンドによって生成された標準出力の一部とは見なされず、通常は特殊な「出力ストリーム」(「標準出力ストリーム」ではなく、いわゆる「標準エラーストリーム」)から生成されます。 )独立して確認または削除し、コマンドの正常な出力を妨げないようにします。

しかし、この場合はgrep実際には不可能です。展示するパターンに一致するデータは、ファイルがバイナリであり、データが印刷できない可能性が高いため、ファイルに一致があるというメッセージを介して通知されます。Binary file IMG_2125.jpg matchesこれは実際に診断警告メッセージではありません。マイクセルフが提案するもの)。


1一部のecho実装では、一部のファイル名にバックスラッシュ文字が含まれている場合は、拡張用のエスケープシーケンスとして解釈します\n\b

おすすめ記事