☰

Windows에서 생성된 txt 파일의 grep이 Mac의 문자열과 일치하지 않습니다. 이유는 무엇입니까? [복사]

tag-icon • tag-icon grep
Windows에서 생성된 txt 파일의 grep이 Mac의 문자열과 일치하지 않습니다. 이유는 무엇입니까? [복사]

동료가 빌드 트리를 생성하고(통과 gradle :dependencies > dependencies.txt) 이를 이메일로 나에게 보냈습니다. 버전을 알고 싶은 라이브러리를 찾아서 다음을 실행했습니다.

grep log4j dependencies.txt

그러나 일치하는 항목이 하나도 없었고 내 쉘은 방금 새 프롬프트를 인쇄했습니다. 파일이 길고 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이 파일을 바이너리로 처리하는 이유는 무엇입니까?

관련 정보