Приходилось ли писать сложные скрипты в Unix

Что проверяют

Живёте ли вы в терминале и понимаете ли, где скрипт пора заменить программой. Для инженера на Go это повседневность: сборка, релизы, разбор логов на сервере, обвязка конвейера.

Как отвечать

Расскажите про конкретные задачи: разбор логов связкой grep, awk и jq, обвязка сборки и выкладки, разовые миграции данных, подготовка окружения в CI. И сразу покажите гигиену, по ней и оценивают:

set -euo pipefail
tmp=$(mktemp -d)
trap 'rm -rf "$tmp"' EXIT

Почему именно так: без -e скрипт продолжает работу после упавшей команды, без pipefail код возврата конвейера берётся от последней команды, а без кавычек вокруг переменной пробел в пути разносит её на несколько аргументов.

Дальше назовите то, что отличает опытного: find -print0 вместе с xargs -0, flock против параллельного запуска из cron, сообщения в поток ошибок, осмысленные коды возврата, shellcheck в проверках.

Закончите границей применимости. Когда в скрипте появляются структуры данных, конкурентность и потребность в тестах, его переписывают на Go. Один статический бинарь без зависимостей на целевой машине обычно и есть правильный финал такой автоматизации.

Где спотыкаются

Называют себя автором сложных скриптов, но не знают про set -euo pipefail. Такой скрипт молча идёт дальше после ошибки и успевает испортить данные раньше, чем кто-то заметит.

Второе: перебирают вывод ls в цикле и не берут переменные в кавычки. Имя файла с пробелом или переносом строки ломает логику, а в скрипте удаления это заканчивается потерей лишнего.

Третье: забывают, что cron стартует с урезанным окружением и без терминала. Скрипт, который работает в интерактивной сессии, там падает на ненайденной команде, и узнают об этом по последствиям, потому что вывод никуда не собирается.