Grep не находит строку, которая точно есть в файле, что делать?

Question

[MatchPlayer77]

Разбирал живую проблему на проде сайта aipredict.one (страница матча зависла со старыми данными) и наткнулся на побочную странность.

На сервере (Ubuntu, GNU grep) искал число в JSON-файле с архивом матчей сайта:

deploy@aipredict:~/aipredict.one$ grep -l '1627588' data/archive/2026-08.json
$

Пусто. Файл существует, права на чтение есть, опечаток в числе нет - проверял несколько раз.

Тут же, для той же самой строки того же самого файла:

$data = json_decode(file_get_contents('data/archive/2026-08.json'), true);
foreach ($data as $rec) {
    if ((string)$rec['fixtureId'] === '1627588') {
        print_r($rec); // находит без проблем
    }
}

PHP находит запись сразу. Файл при этом один и тот же, между командами не менялся.

Вопрос: почему grep мог не найти подстроку, которая физически есть в файле и успешно вычитывается другим инструментом? Дайте хотя бы 2-3 гипотезы, объясняющие такое поведение, и как проверить каждую.

Comments

[Adamos]

grep не обязан работать со строками длиннее 2048 байт.
https://superuser.com/questions/1703029/is-there-a...

[rPman]

Adamos, там просто пространные размышления о том что 'не обязан', но у нас gnu реализация (маловероятно что автор использует busybox grep да и та скорее всего без лимита), с огромными строками должно работать.

Автору вопроса, вместо того что бы гадать, посмотрите 'глазками' на проблемное место в файле, например hex просмотрщиком или far commander (у него встроен viewer, простой, дубовый и работающий с терабайтными файлами, и главное поиск там работает, но осторожно с кодировками, не ваш случай, у вас цифры).

[Adamos]

rPman, проблемность по байтам и кодировкам автор отсек проверкой, приведенной в вопросе.

[Lynn «Кофеман»]

Безумная гипотеза: кто-то записал строку с экранированием.
Типа такого
'1627588' == '162758\x38'

[xotkot]

посмотрите вывод без флага -l:
grep '1627588' data/archive/2026-08.json
возможно grep наткнулся на нулевой байт и решил что файл бинарный и соответственно поменял режим поиска с текстового на бинарный
тогда вывод будет подобен

grep: data/archive/2026-08.json: двоичный файл совпадает

можете еще глянуть вывод:
file data/archive/2026-08.json
покажет какой формат файла

если это действительно так то можно принудительно зафиксировать текстовый режим в grep с помощью флагов -a, --text
о чем в принципе вам ниже в ответах и написали
можно даже и так без флага но преобразовав файл заранее:
strings data/archive/2026-08.json | grep '1627588'

[Adamos]

xotkot, на файл с нулем json_decode выдает null.

[Telcontar]

Какая кодировка у файла? Не UTF-16 часом?

[Olesya Dekhand]

1.Бинарные данные / BOM – Файл может содержать нулевые байты или UTF‑8 BOM (EF BB BF). grep по умолчанию избегает бинарные файлы, поэтому он ничего не выводит. Проверьте с помощью file -i и принудительно treat as text с grep -a.
2.Скрытые не-Ascii-байты – Предварительный слэш, пробел, zero‑width space или Windows CR (\r) перед числом нарушает точное совпадение grep. Выявите это с помощью sed -n '…p' … | cat -A и очистите их (tr -d '\r').
3.grep работает в режиме регулярных выражений – Если вы используете grep -E (или алиас, который принудительно использует регулярные выражения), шаблон обрабатывается как регулярное выражение; опции типа -w (слово) могут требовать границ слов, которых нет. Убедитесь, что вы используете базовый текст (grep -F).

[Adamos]

Olesya Dekhand, вот теперь от нейрослопа не продохнуть. ЕИ не подключался вовсе.

[Olesya Dekhand]

Спасибо за комментарий. Вижу, что" тролль" вступил в диалог, но, к его сожалению, нейросеть уже завершила обработку этого запроса. Вопрос исчерпан, тема закрыта. Желаю продуктивного дня без лишних троллингов.
P.S. "Нейрослоп".

[xotkot]

судя по вашему дублю вопроса на stackoverflow

$ file 2026-08.json
2026-08.json: Unicode text, UTF-8 text, with very long lines (42326), with no line terminators

файл большой(9M), текстовый, в одну строку
но, например, у меня находит значения без проблем как и у тех кто отписался там под одним из ответов

к вопросу думаю следует еще добавить и версию grep которую вы используете
grep -V
да и уточнить систему под которой это работает
может там какой-то BusyBox с урезанной grep утилитой ?

Answer 1

[Rsa97]

А точно grep ничего не выводит? Вы просите его вывести только имя файла, в котором есть нужная строка (ключ -l). Предполагаю, что имя то выводится.
А вообще для работы с JSON в линуксе есть команда jq.
Аналог вашего PHP-кода:

jq '.[] | select(.fixtureId == "1627588")' data/archive/2026-08.json

Comments

[MatchPlayer77]

Нет - в условии написано прямым текстом: команда выполнена, вывод пустой ($ сразу после промпта, без единой строки). Так что дело не в -l

[Виктор Таран]

Бро он прав , переходи на JQ я тоже работал через grep но потом понял что по факту через jq все стабильнее, там простой синтаксис, и да с регулярками у меня нет проблем так что, это не от принципа я не разобрался с grep сделал как сумел, нет. Тут просто реально jq подходит лучше, ставится с репозиториев без костылей.

Answer 2

[AUser0]

О! Был у меня такой кейс!

Вероятно GREP обнаруживает в файле не-ASCII символ (0xFF например), и из-за этого (ошибочно?) считает файл бинарным, и по какой-то логике не находит требуемый текст.

Укажите GREP-у аргумент --text, может сработать.

Answer 3

[Zerg89]

Файла с путем data/archive/2026-08.json несуществует, путь должен быть либо полным от корня /data/archive/2026-08.json либо относительным каталога в котором вы находитесь ./data/archive/2026-08.json

Comments

[Adamos]

$ grep 'клад' local_file.txt 
Докладчик врет

[Zerg89]

Adamos, не понял, у вас четко файл указан, не путь data/file.txt, файл без пути работать будет так как мы ищем файлы в текущем каталоге
Или grep в данном случае воспринимает его как параметр, тоесть содержит в имени файла подстроку data/file.txt?
Тогда для подпапок надо директиву менять на -lr

[Adamos]

$ grep 'клад' data/local_file.txt 
Докладчик врет

[Adamos]

Вы путаете с командами - если в папке лежит исполняемый файл, то его можно запустить только с точки, иначе оболочка ищет его среди системных команд.
Если же файл - параметр, то очевидно, что относительный путь требует добавления текущей папки, никаких точек не требуется. Абсолютный путь, конечно, ничего не испортит, но не обязателен.

[Zerg89]

Adamos,

user$ cd data
user$ grep -l '123' data/2026-08.json
grep: data/2026-08.json: No such file or directory
user$ ls
2026-08.json
user$ cat 2026-08.json
123
user$
user$ grep -l '123' ~/data/2026-08.json
/tmp/user/home/data/2026-08.json

[Adamos]

Zerg89, найди ошибку сам.

[Zerg89]

Adamos,

grep -l '1323' ~/data/2026-08.json
user$

У меня только так его кейс воспроизводится тоесть ошибка в самом числе файл есть

То что он необязателен я уже понял но лучше так не делать перестанет он сам подставлять неправильно(имхо) и скрипты перестанут работать

[Adamos]

Zerg89, какие "скрипты"?
ТС из конкретной папки набрал команду для конкретного файла (подозреваю, что даже не ручками, а TAB-ом автоподставил).
Совершенно естественное ежедневное использование командной строки по назначению.
Сожалею, что стал комментировать этот ответ и его теперь нельзя просто удалить за бессмысленностью.