sed выдает недопустимую ошибку арифметического оператора

То, что GNU grepсчитает не -текстом, зависит от версии и локали.

В первом приближении можно попробовать:

grep -anPe '^((?!.*$)|.*\0)' < file.log

То есть ищите строки, содержащие символ NUL, 0 байт (, которые, вероятно, являются причиной этого сообщения Двоичный файл , если ваш файл журнала был усечен, когда он был открыт для записи каким-либо процессом без O _APPEND )или не -символы (возможны, если вы находитесь в локали с многобайтовой кодировкой, такой как UTF -8, и некоторые строки были выведены в другой кодировке ).

Это предполагает, что ваш GNU grepбыл собран с поддержкой PCRE (для-P).

Вы можете захотеть направить этот вывод на что-то вроде sed -n l, hexdump -Cилиod -vtc -tx1(и, возможно, опустить параметр -nдля grep), чтобы попытаться идентифицировать те последовательности байтов, которые вызывают двоичный код . сообщение.

Обратите внимание, что grep -aне пропускает эти строки, он просто указывает GNU grepне обрабатывать файлы, которые он рассматривает как двоичные . Строки с этими 0 байтами или символами, отличными от -, все равно будут сообщены, если они соответствуют шаблону.

По крайней мере, в Linux и большинстве собственных файловых систем вы можете определить, является ли файл разреженным, т. е. имеет ли он нераспределенные части (дыры ), которые кажутся заполненными нулевыми байтами с помощью:

perl -le '
  seek STDIN,0,4 or die; $hole = tell STDIN;
  seek STDIN, $hole, 3 and $data = tell STDIN;
  seek STDIN, 0, 2; $end = tell STDIN;
  if ($hole != $end) {
    print "at least one hole at offset $hole, length ".(($data||$end) - $hole)
  }' < file.log

Дыры будут создаваться всякий раз, когда пробел в противном случае будет включать по крайней мере один полный блок файловой системы (, обычно 4 КБ ). Вероятно, по обе стороны от этой дыры будет больше байтов NUL.