![]() It would certainly render the choice of substring algorithm or JIT mostly useless, for example. Unicode normalization negates most if not all of the "clever" optimizations used by GNU grep. I don't know of any search tool that does Unicode normalization, probably exactly because of the performance overhead. debian shipped for a while with the unorm patches, but this caused huge performance regressions on UTF-8 locales. > it cannot do unorm, thus fails to find some unicode patterns. So, umm, yeah, there are plenty of excuses for it. It's not the case that a JIT is always faster than a DFA (or a lazy DFA in GNU grep's case). > extended pattern matching is not jitted. It's hard to beat a well place memchr or a simpler prefilter SIMD approach. I don't even think Hyperscan implements it. And as for EPSM, I don't know of any place where that's used in practice. And neither of them require platform specific vector instructions, so there will be a place for them for a while yet. ![]() even ripgrep does not use the state of the art EPSM substring search.īoyer-Moore is still quite serviceable. > it uses a very old and outdated substring search algorithm. Things like \b and \w are Unicode-aware, for example. GNU grep does have some Unicode support when using the UTF-8 locale. I'll probably create myself some function for this, because it's not fun to type.> and unicode support would also be a good idea. ![]() From that, I could come up to my favorite option: $ tar -xf tarball.tgz -to-command='grep -Hn -label="$TAR_ARCHIVE/$TAR_FILENAME" C || true' Now, pointed me to that answer on the Unix StackExchange. grepping logs where the first line of the files is rarely the interesting matches. That is easy enough to remember, and works quite well for e.g. Tarball.tgz:5:b.txt0000664�3���3���0000000001613554050301013357 0ustar jlehuenjlehuenC I had a file which grep on cygwin considered binary because it had a long dash (0x96) instead of a regular ASCII hyphen/minus (0x2d). We also get some noise, namely the tar format: $ zgrep -Hna 'C' tarball.tgz ![]() That will work almost as good as tar -xOzf tarball.tgz | grep -Hn 'C', where we don't get the individual filenames, and the line-numbers are over the whole tar output. Process a binary file as if it were text this is equivalent to the -binary-files=text option. The easiest way around that is to add an option to zgrep: -a, -text That explains all the output I was getting. Some more information about the file: Linux prompt>file logfile.log logfile. gzips that tar file into a gzipped tar file.Īs I was suspecting, zgrep or zcat will only do a gunzip, and be left with a tar file which is still binary. There seems to be some character, telling grep that the file is not a textfile, but a binary file, causing grep to stop working.packages all files (which happen to be text only in my example) into a tar file (which is binary).Is there a nice (easy and concise) way to do this? The only way I can think of, to get the results I want, would involve a bit more scripting to extract the tarball and run grep in a loop. Of course, if I now ask for filenames and line-numbers, I don't get anything useful. So finally, I got to this solution which works OK: $ tar -xOzf tarball.tgz | grep 'C' I guess zcat (and zgrep) do a gunzip but no tar -xf? If I look at zcat I can see the same output as if I had just done tar -c. But still, I get this exact same "Binary file (standard input) matches" message. Second, I thought to zcat the tarball and use a regular grep on that. It does tell me whether there is a match, it can even count them, but I can't find a way to have the matches printed. What did I try?įirst, I expected that zgrep 'pattern' tarball.tgz would simply work. Seeing the original file-name and line-number before the match would be nice, but I most importantly want to see the matched lines. Now, I want to grep through the files in the tarball. cat grep idiom could work, but I dont know how to make grep ignoring lines (and treat the file as binary). I want to see which files match regular expression 0 , ignoring the line end character(s). Let's also imagine that the files have now been put in a gzipped tarball. AFAIK the find command (or grep) can only match a specific string inside the text file. Let's say I have two files a.txt and b.txt with some content.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |