A colleague created a build tree (via gradle :dependencies > dependencies.txt
) and emailed it to me. I grepped for a library I wanted to know the version of so I executed:
grep log4j dependencies.txt
but got zero matches and my shell just printed a new prompt. Since it was a long file and I trusted grep, I didn't open it and check. Then after a lot of back-and-forth discussion I was told that the file was created on a Windows machine. Even then I was surprised that grep wouldn't work - the search string isn't interrupted by newlines. But after executing:
dos2unix dependencies.txt
Grep started showing the matches I wanted.
Obviously my understanding of how grep works was incorrect. Why would grep not behave the same way on file contents on different operating systems when the search term occurs without any newlines in between?
Further info
file dependencies.txt
returnsdependencies.txt: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators
LC_ALL=C grep log4j dependencies.txt
returns nothinggrep o dependencies.txt
returnedBinary file depdencies.txt matches
grep --text dependencies.txt
returned nothing
dependencies.txt: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators
– Sridhar Sarnobat Mar 03 '21 at 19:04LC_ALL=C grep log4j dependencies.txt
still no matches. But I see we are getting somewhere – Sridhar Sarnobat Mar 03 '21 at 19:06iconv -f utf-16 -t utf-8 dependencies.txt | grep log4j
works. I've seen in the past that there are about 8 env variables one can set to fix some wrong behavior but I am wondering if that will work here. Hopefuly something like that can be used in a set-and-forget fashion – Sridhar Sarnobat Mar 03 '21 at 19:10