☰

Windowsで生成されたtxtファイルのgrepがMacの文字列と一致しません。なぜですか？ [コピー]

tag-icon • tag-icon grep
Windowsで生成されたtxtファイルのgrepがMacの文字列と一致しません。なぜですか？ [コピー]

同僚がビルドツリーを作成し（通過gradle :dependencies > dependencies.txt）、それを電子メールで送信しました。バージョンを知りたいライブラリを見つけて、以下を実行しました。

grep log4j dependencies.txt

しかし、一致するものが1つもなく、私のシェルは新しいプロンプトを印刷しました。ファイルが長くてgrepを信頼しているので、開いて確認しませんでした。しばらくの間に行った後、ファイルがWindowsコンピュータで作成されたと言われました。それにもかかわらず、grepが機能しないという事実に驚きました。検索文字列は改行文字のため中断されません。しかし、実行後：

dos2unix dependencies.txt

Grepは私が望む一致を表示し始めます。

grepの仕組みについての私の理解は間違っているようです。クエリの間に改行がない場合、grepがオペレーティングシステムによってファイルの内容によって異なる動作をするのはなぜですか？

追加情報

  • file dependencies.txt返品dependencies.txt: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators
  • LC_ALL=C grep log4j dependencies.txt何も返さない
  • grep o dependencies.txt返品Binary file depdencies.txt matches
  • grep --text dependencies.txt何も返されませんでした

ベストアンサー1

UTF-16テキストは16ビットフラグメントで構成されているため、各文字は少なくとも二つバイト。 ASCII文字の場合、他のすべてのバイトは0バイトです（\0文字0以外のNULバイト）。 Macがこの問題を処理するように設定されていない可能性があります。

特に、CのNULバイトは文字列ターミネータとして扱われるため、多くのツールでこれをまったく処理できない可能性があります。処理できるとしても、各 NUL を異なる文字で処理できるため、l.o.g.4.j文字列を一致させるにはこのような文字が必要です。

しかし、興味深いことに、NULバイトは印刷時に表示されないため、catファイルを端末に送信すると正常に見えることがあります。

NULはgrepがファイルバイナリを考慮する理由でもあります。

また見なさい:grepがファイルをバイナリとして扱うのはなぜですか？

おすすめ記事