Как найти источник запуска команды при входе в систему на Debian 12

Вы заменили neofetch на fastfetch, но при каждом входе в терминал всё равно видите раздражающее сообщение «-bash: neofetch: command not found». Кажется, система упорно пытается запустить удалённую утилиту, но где именно прописан этот вызов? Давайте разберёмся шаг за шагом – даже если вы уже проверили стандартные конфиги в домашней директории, решение может оказаться в неочевидном месте.

Где искать скрытые точки запуска

Первое, что приходит в голову – проверить файлы инициализации оболочки. Но если .bashrc, .bash_profile и .profile чистые, стоит копнуть глубже. Bash при старте обращается не только к пользовательским, но и к системным конфигурациям. Вот полный маршрут поиска:

1. /etc/profile – главный системный скрипт, выполняемый для всех пользователей при входе в login shell
2. /etc/profile.d/*.sh – каталог для дополнительных скриптов (часто используется в пакетных установках)
3. /etc/bash.bashrc – глобальный аналог .bashrc
4. ~/.bash_login и ~/.bash_logout – редко используемые, но потенциальные кандидаты

Кстати, именно в /etc/profile.d/ многие пакеты (включая neofetch) автоматически добавляют свои скрипты при установке. Проверьте этот каталог командой:

sudo grep -R 'neofetch' /etc/profile.d/

Совет: Используйте grep -F для точного поиска строки – иногда символы в скриптах могут интерпретироваться как регулярные выражения.

Когда grep не помогает: альтернативные методы

Если поиск по файловой системе ничего не дал, возможно, вы столкнулись с одной из этих ситуаций:

• Динамическая генерация скриптов – некоторые инструменты создают временные файлы при установке
• Символические ссылки – оригинальный файл мог быть перемещён или удалён
• Текстовые артефакты – команда могла быть частью сложной конструкции вроде $(neofetch)

Попробуйте метод трассировки:

bash -x -l -i

Эта команда запустит новую оболочку с подробным выводом всех выполняемых инструкций. Ищите в выводе строку с neofetch – она покажет, из какого файла идёт вызов.

Особые случаи: tmux и окружения

Использование tmux – это важный нюанс. Сессии tmux сохраняют состояние окружения, поэтому:

1. Проверьте ~/.tmux.conf на наличие команд инициализации
2. Убедитесь, что не используется плагин менеджера (например, TPM) с собственными скриптами
3. Полностью завершите все сессии tmux перед тестированием изменений

Если проблема проявляется только в существующих сессиях, попробуйте создать новую:

tmux new -s test_session

Ловушка: Некоторые дистрибутивы добавляют свои скрипты в /etc/bash_completion или /etc/environment – проверьте и эти файлы.

Практическое решение: пошаговый чеклист

1. Откройте терминал без tmux (если возможно)
2. Выполните цепочку проверки:

grep -rH 'neofetch' ~/.bash* /etc/profile /etc/profile.d/* /etc/bash.bashrc

3. Для системных файлов используйте sudo:

sudo grep -rH 'neofetch' /etc/{profile,profile.d,bash.bashrc}

4. Если ничего не найдено, проверьте переменные окружения:

env | grep -i 'neofetch'

5. В крайнем случае – создайте символическую ссылку для перехвата вызова:

sudo ln -s /usr/bin/fastfetch /usr/local/bin/neofetch

Типичные ошибки	Решение
Пропущены файлы с правами root	Используйте sudo с grep
Скрипт в /etc/profile.d/ с другим расширением	Ищите все файлы: grep -r /etc/profile.d/
Кэшированные сессии оболочки	Перезагрузите систему или завершите все процессы bash

Если всё это не помогло, остаётся ядерный вариант – добавить отладочные точки в системные скрипты. В начало /etc/profile вставьте:

echo "Выполняется /etc/profile" > /tmp/bash_debug.log

И последовательно перемещайте эту строку вниз по файлу, пока не найдёте момент, когда возникает вызов neofetch. Трудоёмко, но эффективно.

Помните: после любых изменений системных файлов обязательно проверяйте синтаксис командой bash -n /path/to/file – это предотвратит ошибки из-за опечаток. А если решите создать симлинк для neofetch, не забудьте потом его удалить, когда найдёте настоящий источник проблемы.