Когда ваш Bash-скрипт дает сбой: систематический подход к устранению неполадок

Устранение неполадок в Bash-скриптах начинается с одного вопроса: произошел ли сбой из-за неправильной команды, другого окружения или неожиданных входных данных? Повторяемая процедура отладки избавляет от гаданий, когда ломается cron-задача, хук развертывания или скрипт резервного копирования.

Используйте шаги ниже, чтобы прочитать сигнал сбоя, отследить, что на самом деле выполнил Bash, и сузить проблему до конкретной команды.

Этап 1: Подготовка и первичная оценка

Прежде чем углубляться в сложные флаги отладки, убедитесь, что у вас есть фундаментальные элементы. Структурированная первичная оценка экономит значительное время.

1. Проверьте сообщение об ошибке и код выхода

Самая непосредственная подсказка — это сообщение об ошибке, выданное оболочкой. Обратите пристальное внимание на упомянутый номер строки, если он указан.

Коды выхода: В shell-скриптах специальная переменная $? хранит статус выхода последней выполненной команды переднего плана. Успешная команда возвращает 0. Любое ненулевое значение указывает на сбой.
```
some_command
echo "Команда завершилась со статусом: $?"
# Если $? равно 127, это часто означает "команда не найдена".
```

2. Проверьте режим выполнения скрипта

Убедитесь, что скрипт выполняется так, как задумано, особенно в отношении интерпретатора, указанного в shebang-строке.

Shebang: Всегда начинайте скрипт с правильной shebang-строки, чтобы определить интерпретатор. #!/bin/bash является стандартным, но #!/usr/bin/env bash часто предпочтительнее для переносимости.
Права: Подтвердите, что у скрипта есть права на выполнение:
```
chmod +x your_script.sh
```

3. Изолируйте среду выполнения

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

Прямой тест: Запустите скрипт напрямую через интерпретатор, минуя возможные проблемы с PATH при запуске просто по имени:
```
/bin/bash ./your_script.sh
```

Этап 2: Включение флагов отладки Bash

Bash предоставляет мощные встроенные флаги, которые могут отслеживать поток выполнения и оценку переменных, что крайне важно для выявления логических ошибок или неожиданного раскрытия.

1. Основные флаги отладки

Эти флаги обычно добавляются в shebang-строку или включаются/отключаются внутри скрипта с помощью set.

Флаг	Команда	Назначение
-n	`set -n`	Читать команды, но не выполнять их (только проверка синтаксиса).
-v	`set -v`	Выводить строки ввода оболочки по мере их чтения (подробный режим).
-x	`set -x`	Выводить команды и их аргументы по мере выполнения (режим трассировки). Это самый мощный инструмент для логических ошибок.

2. Использование режима трассировки (`set -x`)

set -x добавляет к выводу каждой выполненной команды знак +, показывая, что именно интерпретирует Bash, включая раскрытие переменных.

Пример трассировки:

Рассмотрим скрипт, который выходит из строя из-за неправильного использования кавычек:

# Фрагмент исходного скрипта
USER_INPUT="Hello World"
echo $USER_INPUT  # Сбой, если USER_INPUT содержал пробелы и был передан другой команде

При запуске с включенным set -x (либо через #!/bin/bash -x, либо set -x в начале):

+ USER_INPUT='Hello World'
+ echo Hello World
Hello World

Если вы подозреваете проблемы с кавычками, вы можете выборочно включить режим трассировки вокруг проблемного участка:

set -x
# Команды, которые работают нормально

# Трассировка только проблемного участка
COMMAND_THAT_FAILS_DUE_TO_EXPANSION
set +x
# Остальная часть скрипта

Лучшая практика: Для отладки всего скрипта используйте #!/bin/bash -x или поместите set -x сразу после shebang.

3. Отладка раскрытия переменных

Многие сбои возникают из-за того, как переменные раскрываются (или не раскрываются). Широко используйте двойные кавычки вокруг переменных ("$VAR"), чтобы предотвратить разделение слов и раскрытие glob-шаблонов, но используйте трассировку (set -x), чтобы увидеть, происходит ли раскрытие так, как ожидалось.

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

VAR="a b c"
printf '[%s]\n' "$VAR"
# Вывод: [a b c]

Этап 3: Обработка распространенных типов ошибок

После активации флагов отладки ошибки обычно попадают в предсказуемые категории.

1. Команда не найдена (Код выхода 127)

Эта ошибка, часто появляющаяся как your_command: command not found, указывает на то, что оболочка не может найти исполняемый файл.

Проверьте PATH: Убедитесь, что каталог, содержащий команду, указан в переменной окружения $PATH в контексте выполнения скрипта.
Используйте абсолютные пути: Если сомневаетесь, используйте полный путь к команде (например, /usr/bin/curl вместо просто curl).

2. Синтаксические ошибки

Они часто связаны с непарными разделителями, неправильным использованием управляющих конструкций (if, for, while) или отсутствующими точками с запятой/переводами строк.

set -n (Без выполнения): Запуск скрипта с set -n заставляет Bash анализировать все без выполнения, часто сразу выявляя незакрытые скобки или отсутствующие fi/done.
Синтаксис условий: Обратите пристальное внимание на [[ ... ]] против [ ... ]. Например, проверка арифметики требует (( ... )) или let, а не стандартных структур проверки.

Пример (Арифметический контекст):
```
# Правильный способ проверить, больше ли A, чем B
A=10
B=5
if (( A > B )); then
    echo "A больше"
fi
```

3. Проблемы с правами доступа и вводом/выводом

Если скрипт запускается, но дает сбой при взаимодействии с файлами или внешними процессами, проверьте права доступа и файловые дескрипторы.

Перенаправление ввода: Если вы перенаправляете ввод из файла, убедитесь, что файл существует и доступен для чтения.
Перенаправление вывода: Проверьте, существует ли целевой каталог и есть ли у пользователя скрипта права на запись.

Предупреждение о SUDO: Если вы запускаете скрипт с sudo, переменные окружения, такие как $PATH, и пользовательские конфигурации (например, .bashrc) часто сбрасываются или изменяются. Команды, которые работают при запуске от обычного пользователя, могут дать сбой под sudo из-за отсутствия контекста или путей.

Этап 4: Логирование и проверки системы

Для скриптов, работающих в фоне (например, через Cron), прямой вывод на терминал недоступен. Надежное логирование необходимо.

1. Перенаправление вывода для отладки

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

# Перенаправить весь вывод в debug.log
./your_script.sh >> debug.log 2>&1

Если используется set -x, вывод трассировки также попадет в тот же файл журнала, предоставляя полную запись потока выполнения и ошибок.

2. Проверка работоспособности системы

Иногда сам скрипт в порядке, но проблема в системном окружении:

Дисковое пространство: Не заканчивается ли на системе дисковое пространство (df -h)? Это остановит операции записи.
Память: Проверьте использование памяти (free -m). Высокое давление на память может привести к сбоям или зависанию внешних команд.
Окружение Cron: Если запланировано через Cron, помните, что задачи Cron выполняются в сильно ограниченном окружении. Всегда явно определяйте необходимые переменные окружения в начале скрипта, если они не гарантированы настройкой задачи Cron.

Сократите путь отладки

Когда ваш Bash-скрипт дает сбой, сначала зафиксируйте код выхода и точную ошибку. Затем подтвердите shebang, права, $PATH, входные файлы и контекст пользователя. Если причина все еще неясна, включите set -x только вокруг подозрительного блока и отправьте фоновый вывод в журнал.

Такой порядок делает устранение неполадок практичным. Вы переходите от самых очевидных доказательств к самой детальной трассировке, не захлебываясь в шуме.