This is basically the same behavior as ripgrep (when using the non-memory map search strategy.) At which point, GNU grep will silently quit. When this flag is set, GNU grep will behave as if a file has no remaining matches if a NUL byte is found. GNU grep also supports a little known flag, -I, which is equivalent to -binary-files without-match. At this point, GNU grep stops searching the file because it has alerted the user that it is a binary file and that a match has been found. GNU grep will continue searching until either no match is found in the entire file (in which there is no output) or until the next match is found, at which point, the match is not printed but instead a Binary file matches message is printed. In particular, once GNU grep detects that a file is binary, by default, it doesn't immediately stop. GNU grep does much better here because it never starts from the premise of "smart" filtering like ripgrep does. In particular, we combine the fact that searches can silently stop with the fact that binary detection differs subtly based on the search strategy, which is entirely opaque to the end user. The overall emergent behavior here ends up being pretty unintuitive. If a NUL byte occurs after that, it isn't seen and the file isn't treated as binary. Conversely, if ripgrep searches a file using memory maps, then it only looks at the first N bytes for a NUL byte. Stated differently, ripgrep will detect a file as binary regardless of where the NUL byte occurs. If ripgrep searches a file using standard read calls and a fixed size buffer, then ripgrep will search the contents of every read call for a NUL byte. ripgrep has two primary ways of reading content from a file, and unfortunately, the binary file detection changes based on which method is used.But in actuality, ripgrep just gave up on the search. Silently quitting at this point is problematic because it has the effect of leading the user to believe that the file contains no more matches. In some cases, however, a NUL byte isn't seen until later in the file, and at that point, it is possible that a match has already been printed. This causes the file to be regarded as binary and it is skipped immediately.
In many cases, a NUL byte will occur within the first read of a file.As a heuristic, we declare that if a file contains a NUL byte, then we treat it as binary data. In general, it is not known whether a file is "binary" or not without actually searching it.Unfortunately, there are a few practical issues with this: That is, we'd like to ignore those files for the same reason that we ignore hidden files or files in your. The reason why ripgrep has this behavior is that the intent is to avoid searching binary files at all. Namely, the issue here is that ripgrep will silently stop searching a file if it believes it is binary. Just as with grep, pass the -a option to forcefully search all binary data (by always treating it as text): WARN I1002 06:48:16.167773 7978 resolver.cpp:69] Creating default secret resolverīinary file marathon-loop-master-43355.log matches $ grep "SharedMemoryIntegrationTest-MesosAgent" marathon-loop-master-43355.log
0 kommentar(er)
