Desc: Why developers need to know bash, зачем разработчику знать bash
Lang: ru
PubTime: December 4, 2019
Tags: bash, bash is usefull
Всем привет!
Сегодня в нашу редакцию поступил вопрос:
А нужен ли
bashфронтенд-разработчику и если нужен, то зачем и на каком уровне?
И на этот вопрос, как обычно бывает, невозможно дать однозначного ответа. В общем случае ответ – нет, не нужен. Скорее всего вас никогда не заставят написать ни строчки на bash. Вас даже не заставят читать bash-скрипты.
Но, в то же время, возможно вы сами захотите пользоваться bash.
Со мной было так: у нас, в HeadHunter принято все ветки в git, именовать по номеру задачи, из внутренней треккер-системы. Аналогично принято добавлять номер задачи в начало каждого commit-сообщения. И, на самом деле, написание commit-сообщения – это довольно тривиальная операция, но ее приходится выполнять по несколько десятков раз за день.
!- Articles/Зачем bash – разработчику/Untitled.png
В какой-то из дней меня достало выполнение одних и тех же операций:
выделить номер ветки, который указан в shell prompt, скопировать его, вставить в начало commit-сообщения.
И я заинтересовался – можно ли как-то автоматизировать эту операцию, ведь вот оно, название ветки, к нему можно получить доступ, вот оно сообщение коммита, и мне повезло, я знал о существовании такой вещи, как git-hooks (подробнее можно прочитать тут).
Оказалось, что если воспользоваться хуком prepare-commit-msg, который выполняет указанный bash-скрипт, ровно за момент до того, как сообщение о коммите запишется в систему, то можно добавить к этому сообщению любую информацию, в том числе и номер ветки.
Получился вот такой скрипт:
# Automatically add branch name to every commit message except merge commit.
COMMIT_EDITMSG=$1 # тут изначальный текст сообщения
# запишем в переменную имя текущей ветки
NAME=$(git rev-parse --abbrev-ref HEAD)
# проверим, что это не merge-commit, так как для него номер ветки добавлять не нужно
MERGE=$(cat $COMMIT_EDITMSG|grep -i 'merge'|wc -l)
# проверим, что номера ветки в названии еще нет (на случай, если мы редактируем
# предыдущий commit-message, в котором уже указана ветка)
DUPLICATE=$(cat $COMMIT_EDITMSG|grep -i $NAME|wc -l)
# наконец, в случае, если это не merge-commit, в тексте коммита нет номера ветки
# и название ветки не HEAD (может быть в некоторых случаях)
if [ $MERGE -eq 0 -a $DUPLICATE -eq 0 -a $NAME != "HEAD" ] ; then
# то мы просто выводим оригинальный текст сообщения, добавив в начало,
# название ветки
echo "$NAME $(cat $COMMIT_EDITMSG)" > $COMMIT_EDITMSG
fi
Примерно так выглядел мой первый опыт написания bash-скриптов. Это было немного больно, долго и потребовало активного использования google, но результат превзошёл ожидания – больше мне не приходилось делать рутинных операций, я больше не могу «забыть указать номер ветки» и не могу в нём ошибиться.
Не важно frontent-разработчик вы или backend – рано или поздно вам, в вашей работе встретится операция, которую вам будет выполнять очень лень, но она будет полезной, и очень нужной. В этом случае, я надеюсь, вы сами вспомните о том, что существует bash и попробуете ее автоматизировать или, хотя бы, облегчить.
А по-поводу необходимого уровня – он может быть любым, но вам важно научиться формулировать свою проблему, чтобы найти решение в поисковике. Все популярные, сложные и не очень, вопросы, уже давно отвечены на каком-нибудь stackoverflow.
На самом деле совсем не обязательно пользоваться именно bash, его основное преимущество в том, что его интерпретатор есть почти в любой операционной системе на базе *unix, в отличие от того же nodejs.
Но вот python почти так же распространён, особенно, если мы говорим о пользовательских системах, поэтому если bash вам не нравится, то просто напишите свою программу на питоне, а на bash напишите одну строку, которая вызовет вашу программу. Или еще проще, используйте «шебанг» #! /bin/python , который скажет операционной системе, что текущий файл нужно интерпретировать не при помощи bash, а при помощи python