И то, и другое интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:
cd /home
То именно интерпретатор ее расшифрует и скажет компьютеру он хочет перейти в директорию /home. Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор переводом с нашего на компьютерный язык.
Так что cd /home это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls (в винде эти команды немного другие)
А что такое shell-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть сложные команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.
См также:
Основные linux-команды для новичка что можно выполнять в консоли
Например, создадим скриптик, который создаст директорию и в ней файлик:
mkdir /home/testcd /home/testtouch test.txt
Так, команды записали, осталось сохранить их в файлик. Скрипты хранят в файлах с расширением .sh, поэтому назовем файл first_script.sh. Но есть нюанс линуксу плевать на ваше расширение файла. Его может вообще не быть, и все равно скрипт останется скриптом. Почему? Потому что у любого скрипта в первой строке должен содержаться путь к интерпретатору. Например:
#!/bin/bashили#!/bin/sh
Весь файл целиком:
#!/bin/bashmkdir /home/testcd /home/testtouch test.txt
И даже если у такого файла не будет расширения вовсе, его можно будет запустить как скрипт:
sh first_script# Проверяем директорию /home там появилась папка test с файлом test.txt внутри.
Расширение .sh ставится для понимания челоком. Зашел в директорию:
Ага, что тут у нас? Файлы sh, скрипты какие-то лежат...
Скрипты могут быть простые, а могут быть сложные. Вот, например, в одном проекте мы вначале вручную обновляли тестовые платформы. Для обновления надо:
-
Остановить сервис.
-
Переподложить war-файл с приложением (лежат они в директории /opt)
-
Запустить сервис
Сервиса два, допустим это test и cloud. Так что шагов уже 6.
Когда обновлять вручную надоело, мы положили на все линукс машины простой скриптик:
#!/bin/bashservice test stopcp test.war /opt/jboss-test/binservice test startservice cloud stopcp cloud.war /opt/jboss-cloud/binservice cloud start
Собираешь приложение, подкладываешь к скриптику и запускаешь 1 команду вместо 6. Удобно! Это называется автоматизация рутины =)
Другой пример с того же проекта мы делали серверное приложение. И во время установки приложения на сервере linux нужно выполнить пункты по настройке самой системы. Например, увеличить параметр max_map_count сколько максимум памяти может использовать процесс.
Приложение в пике работы требует много памяти. Если не настроить параметр, то тяжеловесная задача просто упадет с ошибкой Не хватает памяти. И если мы видим такую ошибку, то в первую очередь идем проверять настройки системы.
Вообще, если вы отдаете установку приложения на откуп чужим админам, лучше потом проверять а всё ли настроено верно? Конечно, обычно на production (машина, с которой работают реальные пользователи) настраивают всё внимательно, это на тестовых стендах могут что-то пропустить... Но лучше перебдеть!
Мы написали скрипт по проверке настройки окружения (символ # в начале строки означает, что это комментарий):
#!/bin/sh## check sysctl#if [ -f /proc/sys/vm/max_map_count ] && [ $(cat /proc/sys/vm/max_map_count) -ge 16777216 ]; thenecho "vm.max_map_count: ok"elseecho "vm.max_map_count: failed"fiif [ -f /proc/sys/vm/overcommit_memory ] && [ $(cat /proc/sys/vm/overcommit_memory) -eq 2 ]; thenecho "vm.overcommit_memory: ok"elseecho "vm.overcommit_memory: failed"fiif [ -f /proc/sys/vm/overcommit_ratio ] && [ $(cat /proc/sys/vm/overcommit_ratio) -eq 100 ]; thenecho "vm.overcommit_ratio: ok"elseecho "vm.overcommit_ratio: failed"fiif [ -f /proc/sys/vm/swappiness ] && [ $(cat /proc/sys/vm/swappiness) -le 10 ]; thenecho "vm.swappiness: ok"elseecho "vm.swappiness: failed"fi
В итоге админы настраивают окружение, а потом мы даем им скрипт, просим запустить его и прислать результаты. Я запустила скрипт на голой системе, где, разумеется, параметры настроены не были, и вот ответ:
Видим, что все проверки провалились, статус failed. Если и от админов приходит похожая картина, направляем их в документацию по настройке системы. Если к нам приходят с проблемой падения из-за нехватки памяти, снова просим выполнить скрипт. Так проще локализовать ошибку: это в приложении косяк, или окружение настроено плохо?
Просить других людей выполнить 10 команд не очень хорошо. Потому что часть команд может потеряться при выполнении плохо скопировал, забыл выполнить проверку, которую дали сообщением позже... Гораздо проще сделать 1 скрипт и попросить выполнить именно его.
Когда надо писать скрипт?
-
Когда надо выполнить больше 3 команд за раз проще выполнить одну, запустить скрипт.
-
Когда одну и ту же команду надо выполнять чаще 3 раз лучше автоматизировать эту работу.
По сути своей, bash-скрипты это та же автоматизация. А когда нужна автоматизация? Когда мы хотим избавиться от рутины, от постоянного выполнения одного и того же действия вручную. Повторяете одно и то же каждый день / неделю? Напишите скрипт. Даже если он на 2-3 строчки будет, это правда удобнее. Поверьте, сама делала небольшие скрипты ?
См также по bash:
Что такое shell и зачем он нужен
Основы BASH. Часть 1 (Хабр) цикл статей о том, как писать скрипты
См также другие статьи из цикла Что такое...:
Что такое клиент-серверная архитектура
Что такое CI (Continuous Integration)
Что такое регулярные выражения (regexp)
PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале
