![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Ситуёвина из моих трудовых будней. Сразу скажу, что не-компьютерщикам, и не-юниксоидам тут будет неинтересно.
Итак, типовая рабочая задача. Пользователь открыл тикет: у него почему-то падает тест. Тест запускает из-под себя некий скрипт и ... получат от системы сообщение "file not found". Ну, первая заповедь суппорта - проверь, а не врёт ли пользователь. И как ни странно, выходит, что файл наличествует. Хоть и локальный, но на том самом компьютере, где всё произошло. И время создания у него вполне надёжное, то есть при запуске теста он точно существовал.
Ладно, думаю, может какой-то глюк (хотя какой может быть глюк в локальной файловой системе?). Приступаю ко второй заповеди: воспроизведи или докажи, что проблема исчезла. Запускаю ту же самую команду, и ... не верю своим глазам - проблема воспроизводится! Вторая заповедь не помогла.
Перехожу к следующей фазе двоичного дерева решений - свести проблему к простейшему примеру и найти точку, где упрощение приводит к нормальному поведению. Дохожу в декомпозиции до самой команды. Запускаю ... и $%@# получаю ту же ошибку. То есть с точки зрения какой нибудь команды "ls" файл имеется, он не пустой, и не симлинк "в никуда". Обычный файл, скрипт на Пайтоне! В таких ситуациях программист начинает придумывать самые фантастические объяснения, вроде вируса в системе. Ага, в линуксе, который за стопицот фаерволами в корпоративной сети, и при этом портится только этот несчастный скрипт.
Добавлю, что никаких фокусов CI с динамическим извлечением файла тут нет, он реально статический и его видят все кто только может. Имя файла правильное, никаких "чудесных" символов в нём нет. Октал дамп не выдаёт ничего подозрительного. Все разрешения на выполнение скрипта - валидные, и разрешают моему аккаунту его запускать, читать и даже модифицировать. Запускаю я его через полный путь, то есть поиска с помощью битого $PATH тут нет.
Короче, проблема была решена без всяких AI-помошников, чисто на собственном более чем 25-летнем опыте. И это оказалась не сигнатура UTF8 и не виндузовая кодировка CR-LF. Когда юзер узнал причину, он прямо офигел.
Даю читателям блога срок до завтра. Если кто может догадаться, что там случилось с несчастным файлом - комментируйте.
Итак, типовая рабочая задача. Пользователь открыл тикет: у него почему-то падает тест. Тест запускает из-под себя некий скрипт и ... получат от системы сообщение "file not found". Ну, первая заповедь суппорта - проверь, а не врёт ли пользователь. И как ни странно, выходит, что файл наличествует. Хоть и локальный, но на том самом компьютере, где всё произошло. И время создания у него вполне надёжное, то есть при запуске теста он точно существовал.
Ладно, думаю, может какой-то глюк (хотя какой может быть глюк в локальной файловой системе?). Приступаю ко второй заповеди: воспроизведи или докажи, что проблема исчезла. Запускаю ту же самую команду, и ... не верю своим глазам - проблема воспроизводится! Вторая заповедь не помогла.
Перехожу к следующей фазе двоичного дерева решений - свести проблему к простейшему примеру и найти точку, где упрощение приводит к нормальному поведению. Дохожу в декомпозиции до самой команды. Запускаю ... и $%@# получаю ту же ошибку. То есть с точки зрения какой нибудь команды "ls" файл имеется, он не пустой, и не симлинк "в никуда". Обычный файл, скрипт на Пайтоне! В таких ситуациях программист начинает придумывать самые фантастические объяснения, вроде вируса в системе. Ага, в линуксе, который за стопицот фаерволами в корпоративной сети, и при этом портится только этот несчастный скрипт.
Добавлю, что никаких фокусов CI с динамическим извлечением файла тут нет, он реально статический и его видят все кто только может. Имя файла правильное, никаких "чудесных" символов в нём нет. Октал дамп не выдаёт ничего подозрительного. Все разрешения на выполнение скрипта - валидные, и разрешают моему аккаунту его запускать, читать и даже модифицировать. Запускаю я его через полный путь, то есть поиска с помощью битого $PATH тут нет.
Короче, проблема была решена без всяких AI-помошников, чисто на собственном более чем 25-летнем опыте. И это оказалась не сигнатура UTF8 и не виндузовая кодировка CR-LF. Когда юзер узнал причину, он прямо офигел.
Даю читателям блога срок до завтра. Если кто может догадаться, что там случилось с несчастным файлом - комментируйте.
Tags:
(no subject)
Date: 2025-08-08 08:14 am (UTC)У нас есть победитель! :-)
Date: 2025-08-08 10:28 am (UTC)Первопричина затыка у юзера была в том, что раньше он запускал свой скрипт на другой системе, где был третий Пайтон. В нашем случае этого интерпретатора на хосте просто не было, вот шелл и ругался.
А вообще, по-хорошему эту "фичу" уже давным-давно надо бы починить. Починили же прикол с командой "cat can", при том что это был милый пранк, а вовсе не баг.