Как улучшить себе жизнь со скриптами bash/btach

Сегодня я хотел написать этот пост, но краткое вступление раздулось до огроменного ставшего в результате самодостаточным поста. Тут же я поделюсь серией подобных практик в одной узкой области - сборка и поставка приложения. А пост этот был написан с использование другой практики - make manual from chat log. Когда ты с коллегой в чате уже обсудили какой-то вопрос, ты настрочил много текста и теперь хочешь его как-то повторно использовать. Так что этот пост, как и многие другие - во многом вдохновлен обсуждением вопроса в чате, скопипащенный оттуда и немного отредактированный. 

Итак погнали. Я ленив, а потому если команду в консоли bash/batch я ранаю второй раз за сегодня, тут же останавливаюсь и начинаю писать bash/batch скрипт: bash для linux, batch для windows. За последние пару лет эта практика меня сильно прокачала в этих сприктовых языках программирования. Если раньше мне приходилось гуглить как делается в OS так или иная операция или выполняется та или иная команда, то сейчас я гуглю особенности различных языковых конструкций: if/else/while/function/ect, как делаются те или иные expression и так далее. Этот язык программирования (вообще правильно command language) весьма специфический и более того их два диалекта - для windows и для linux. Почему диалекта, потому что очень многое слизано (как мне кажется) у windows с linux. Отличия все же приходится гуглить. 

Раньше я писал скрипты для обоих OS. Но в последнее время склоняюсь в сторону linux, а для тех, кто работает под windows предлагаю для запуска моих bash скориптов использовать что-то типа cygwin или mingw. Очень в немногих местах приходится проверять OS и менять поведение скрипта в зависимости от OS. Но это куда лучше чем писать две версии скриптов, либо лишать windows пользователя инструмента автоматизации. 

Идем дальше. Загнать тот скрипт, который ты обычно ранаешь в консоли в текстовый файл и назвать с расширение bat/sh это первый шаг, но этого недостаточно. Часто новички в DevOps часто используют команду cd для того, чтобы направиться в определенную папку, и там уже выполняют команду. Я же пришел к тому, что каждую команду стоит выполнять в абсолюте.
Все что выполняется относительно, всегда потом дает повод поиграться с ним в самый неподходящий момент.

cd ./some/place/in/project
ls -la
cd ../../..
cat file.txt

В суппорте такой подход требует от меня всегда помнить "где я?". То есть для каждой строчки надо помнить 2 вещи - ЧТО делаем, ГДЕ делаем. А если ты юзаешь всегда только абсолютный путь, тогда все чисто.

ls -la /srv/app/some/place/in/project
cat /srv/app/some/file.txt 

Более того, рекомендовано использовать такие команды даже когда ты работаешь в консоли руками. Если говорить про linux то там в папке твоего юзера есть ~/bash_history файл и в нем все команды когда-либо выполняемые тобой на этой машине. Очень информативно видеть там самодостаточные команды, выполнив которые из любого места системы будет один и тот же эффект.

Но как быть с дублированием? Допустим я не хочу постоянно вбивать /srv/app/some

ls -la /srv/app/some/place/in/project
cat /srv/app/some/file.txt

В скрипте (bash) сделать так

root=$(pwd)
ls -la $root/place/in/project
cat $root/file.txt

В batch вот так 

set root=%cd%
dir %root%\place\in\project
type %root%\file.txt

Следующим шагом я бы улучшил информирование в консоли (bash). 

BLUE=94
GRAY=89
YELLOW=93

color() {
    message=$1
    [[ "$2" == "" ]] && color=$YELLOW || color=$2
    echo "[${color}m${message}"
}

eval_echo() {
    command=$1
    [[ "$2" == "" ]] && color=$BLUE || color=$2
    color "${command}" $color
    echo
    eval $command
}

eval_echo "set root=%cd%"
eval_echo "dir %root%\place\in\project"
eval_echo "type %root%\file.txt"

echo
color "Press Enter to continue"
read

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

 

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

Удобство этого подхода в том, что вместо переменных типа $root будет вставлено реальное значение и на экране напечатается информативная команда, именно та, что будет реально вызвана. 

А если не хочется копипастить из скрипта много кода, то напомню, что самый минималистичный вариант eval_echo это

eval_echo() {
    echo "$1"
    eval $1
}

Обрати внимание, что в этом коде есть ESC символ. 

 

Благодаря этому символу в linux консоли можно рисовать цветом. Под bacth есть подобный подход.

Все это сильно позволяет ускориться во время выполнения обычных рутинных действий: залить ветку на github со всеми subrepo, pull всех subrepo, автоматическая генерация каких-то ресурсов, создание snapshot для всех артефактов, создание запускного jar для каждого компонента с автоматически сгенерированными скриптами запуска, запуск сервера в целях отладки в определенной конфигурации, дамп базы и так далее. Все это делалось вручную раньше, а сейчас на это не тратится время. Время (сильно меньше) тратится на поддержание скриптов. Это экономически выгодно, иначе небыло бы DevOps с CI/CD и мы собирали war вручную или с Ant, заливали бы его в папку Tomcat на сервере, разбирались бы с конфликтом jar, как делали это 10 лет назад. Деплой бы занимал не 1 клик и 10 минут, а 1 час и много ручной работы.