Shell и bash в чем разница

В чем разница между #!/bin/sh и #!/bin/bash?

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

Это особенно актуально для пользователей Linux и его дистрибутивов. Использование командного терминала для выполнения обычных задач довольно распространено.

Программы, работающие за кулисами командного терминала, называются «оболочками». Оболочки определяются как программы, которые принимают команды, интерпретируют их, а затем предписывают компьютеру выполнить функцию, которую хочет выполнить пользователь. Таким образом, все, что вы кодируете, является частью оболочки.

В Linux пользователи используют язык программирования под названием «sh» для написания кода в оболочке. «Sh», также известный как «Bourne Shell», был разработан для использования с системами UNIX, определенными с использованием стандартов POSIX.

«Bash» также является языком программирования оболочки. Он также известен как «Bourne Again Shell». Сегодня Bash является языком программирования по умолчанию для оболочек в Linux. Bash обладает теми же возможностями, что и Shell, но со временем в нем появились другие функции и лучшие расширения.

Если вы пользователь Linux и хотите узнать разницу между Shell и Bash, вы попали в нужное место, так как мы будем углубляться и описывать различия между двумя языками программирования оболочки.

Бин/ш

До сих пор мы установили, что «sh» называется «Shell», и это язык программирования оболочки для систем на базе UNIX. Мы также сказали, что он соответствует стандартам POSIX. Стандарты POSIX были разработаны IEEE для обеспечения совместимости различных операционных систем. Таким образом, стандарты POSIX гарантируют, что все, что разработано с использованием оболочки, может быть использовано и в других операционных системах.

Оболочку лучше описать как спецификацию, а не как реализацию. Реализация может быть описана как полный язык программирования со своими отдельными компиляторами, такими как C и C++.

Shell не похож на традиционный язык программирования. Таким образом, это нельзя назвать реализацией. Оболочка подробно описывает синтаксис и семантику, используемые для программирования в оболочке Linux.

Для разных операционных систем оболочка может быть связана с разными реализациями. Например, Shell имеет реализацию «dash» в Linux, «Z shell» для Mac и «ash» для OpenWRT.

Бин/баш

Bash можно назвать реализацией Shell, разработанной для проекта GNU. Как упоминалось ранее, он включает в себя все функции оболочки, но имеет улучшенные расширения. Следовательно, его также можно назвать надмножеством оболочки, включая идеи, взятые из других оболочек, таких как оболочка C.

Bash можно использовать как для написания сценариев, так и для реализации. В режиме реализации bash принимает форму командного терминала современного Linux. Для Ubuntu оболочка сценариев — dash, а терминал по умолчанию — bash.

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

Вот некоторые из функций, которые являются эксклюзивными для Bash.

Замена процесса
Переменные области видимости
Массивы
Bash поддерживает множество специальных переменных, таких как $RANDOM, $SECONDS и т. д.

Преимущества использования оболочки

Сценарии оболочки выполняются с использованием всех типов оболочек. Поскольку Bash является наиболее распространенным и наиболее используемым, есть очевидные преимущества bash по сравнению с оболочкой. Но при использовании Shell по сравнению с Bash есть большое преимущество, которое заключается в переносимости.

Поскольку оболочка соответствует стандартам POSIX, сценарий, написанный в оболочке, можно без проблем использовать в любой системе Linux. Чего нельзя сказать о Баше. По мере того, как в Bash добавлялись лучшие расширения и функции, он постепенно отходил от стандартов POSIX, что влияло на его переносимость.

Преимущества использования Bash

Как упоминалось ранее, Bash имеет более продвинутые функции, чем Shell. Наличие более продвинутых функций просто делает Bash более удобным и эффективным в работе. Вот почему Bash используется чаще, чем Shell.

Большим преимуществом Bash является то, что его можно легко отлаживать по сравнению с Shell. Поиск ошибок и исправление сценариев в Shell значительно сложнее, чем поиск ошибок в сценарии, написанном на Bash.

Мы упоминали, что Bash отклонился от стандартов POSIX. Но если пользователь хочет сделать Bash более поддерживающим POSIX, Bash предлагает функцию переключения POSIX. Его можно включить, введя следующую команду.

$ bash —posix

Заключение

В этой статье обсуждались, что такое оболочки и языки, которые пользователи могут использовать для написания сценариев оболочки. Двумя основными языками, которые появились, были Shell и Bash. Мы подробно описали их обоих, чтобы мы могли правильно объяснить различия. Bash — это более новая и улучшенная версия Shell, поэтому мы проголосовали за лучший язык оболочки. Предлагаемые функции и преимущества Bash над Shell очень велики. Таким образом, выбрать Bash вместо Shell для написания наших сценариев Shell очень просто.

Мы надеемся, что смогли ясно объяснить различия и что теперь вы знаете, с чем имеете дело при использовании Shell или Bash. Мы также надеемся, что выбор между Shell и Bash стал для вас проще.

Разница между sh, dash, bash и т.д?

Вот такой выбор предлагает VestaCP. Вопрос: чем они различаются?

Вопрос задан более трёх лет назад
12171 просмотр

Комментировать
Решения вопроса 3

CityCat4

Внимание! Изменился адрес почты!

/bin/sh — Это Bourne Shell версии 1.0
/bin/bash — Это Bourne Shell версии 2.0

Соответственно в баше работает все написанное для /bin/sh. Отличаются они тем, что читают разные файлы при старте. /bin/sh — читает .profile. /bin/bash — читает .bash_profile.

Если учетка для себя (или вообще для пользователя) — ставьте bash. Если для автомата — /bin/sh, так проще

Ответ написан более трёх лет назад
Комментировать
Нравится 3 Комментировать

uvelichitel

uvelichitel @uvelichitel
habrahabr.ru/users/uvelichitel

bash при запуске надежно прочитает ~/.bashrc куда обычно и вписывают исполняемые пути и переменные окружения
будут работать все скрипты, сниппеты и советы полученные гуглением

Что такое bash / shell

И то, и другое — интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:

cd /home

То именно интерпретатор ее расшифрует и скажет компьютеру «он хочет перейти в директорию /home». Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор — переводом с «нашего» на «компьютерный» язык.

Так что «cd /home» — это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls… (в винде эти команды немного другие)

А что такое shell-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть «сложные» команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.

Например, создадим скриптик, который создаст директорию и в ней файлик:

mkdir /home/test cd /home/test touch test.txt

Так, команды записали, осталось сохранить их в файлик. Скрипты хранят в файлах с расширением .sh, поэтому назовем файл first_script.sh. Но есть нюанс — линуксу плевать на ваше расширение файла. Его может вообще не быть, и все равно скрипт останется скриптом. Почему? Потому что у любого скрипта в первой строке должен содержаться путь к интерпретатору. Например:

#!/bin/bash или #!/bin/sh

Весь файл целиком:

#!/bin/bash mkdir /home/test cd /home/test touch test.txt

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

sh first_script # Проверяем директорию /home — там появилась папка test с файлом test.txt внутри.

Расширение .sh ставится для понимания человеком. Зашел в директорию:

— Ага, что тут у нас? Файлы sh, скрипты какие-то лежат.

Скрипты могут быть простые, а могут быть сложные. Вот, например, в одном проекте мы вначале вручную обновляли тестовые платформы. Для обновления надо:

Остановить сервис.
Переподложить war-файл с приложением (лежат они в директории /opt)
Запустить сервис

Сервиса два, допустим это test и cloud. Так что шагов уже 6.

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

#!/bin/bash service test stop cp test.war /opt/jboss-test/bin service test start service cloud stop cp cloud.war /opt/jboss-cloud/bin service 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 ]; then echo "vm.max_map_count: ok" else echo "vm.max_map_count: failed" fi if [ -f /proc/sys/vm/overcommit_memory ] && [ $(cat /proc/sys/vm/overcommit_memory) -eq 2 ]; then echo "vm.overcommit_memory: ok" else echo "vm.overcommit_memory: failed" fi if [ -f /proc/sys/vm/overcommit_ratio ] && [ $(cat /proc/sys/vm/overcommit_ratio) -eq 100 ]; then echo "vm.overcommit_ratio: ok" else echo "vm.overcommit_ratio: failed" fi if [ -f /proc/sys/vm/swappiness ] && [ $(cat /proc/sys/vm/swappiness) -le 10 ]; then echo "vm.swappiness: ok" else echo "vm.swappiness: failed" fi

В итоге админы настраивают окружение, а потом мы даем им скрипт, просим запустить его и прислать результаты. Я запустила скрипт на «голой» системе, где, разумеется, параметры настроены не были, и вот ответ:

Видим, что все проверки провалились, статус failed. Если и от админов приходит похожая картина, направляем их в документацию по настройке системы. Если к нам приходят с проблемой падения из-за нехватки памяти, снова просим выполнить скрипт. Так проще локализовать ошибку: это в приложении косяк, или окружение настроено плохо?

Просить других людей выполнить 10 команд не очень хорошо. Потому что часть команд может «потеряться» при выполнении — плохо скопировал, забыл выполнить проверку, которую дали сообщением позже. Гораздо проще сделать 1 скрипт и попросить выполнить именно его.

Когда надо писать скрипт?

Когда надо выполнить больше 3 команд за раз — проще выполнить одну, запустить скрипт.
Когда одну и ту же команду надо выполнять чаще 3 раз — лучше автоматизировать эту работу.

По сути своей, bash-скрипты — это та же автоматизация. А когда нужна автоматизация? Когда мы хотим избавиться от рутины, от постоянного выполнения одного и того же действия вручную. Повторяете одно и то же каждый день / неделю? Напишите скрипт. Даже если он на 2-3 строчки будет, это правда удобнее. Поверьте, сама делала небольшие скрипты =)

См также по bash:

Основы BASH. Часть 1 (Хабр) — цикл статей о том, как писать скрипты

См также другие статьи из цикла «Что такое. »:

Bash vs shell

Уважаемые знатоки объясните новичку, чем отличается bash от shell`a просто не могу понять в чем между ними разница.

P.S В гугле не нарыл.

orionit
11.10.15 16:49:19 MSK

Ныне /bin/sh это алиас на что-нибудь в системе, но изначально bash это расширение обычного sh. Если скрипт с башизмами — то использовать нужно /bin/bash, если POSIX-совместим — то /bin/sh.

Bfgeshka ★★★★★
( 11.10.15 16:55:56 MSK )

bash это bourne again shell.

Deleted
( 11.10.15 16:58:06 MSK )
Ответ на: комментарий от Bfgeshka 11.10.15 16:55:56 MSK

Спасибо за ответ все понятно, но не могли бы вы привести пример отличия bash от sh. p.s Крохотный пример.

orionit
( 11.10.15 17:00:07 MSK ) автор топика

чтобы понять разницу тебе надо понять что такое командный интерпретатор

reprimand ★★★★★
( 11.10.15 17:02:59 MSK )
Ответ на: комментарий от orionit 11.10.15 17:00:07 MSK

Bfgeshka ★★★★★
( 11.10.15 17:05:00 MSK )
Ответ на: комментарий от orionit 11.10.15 17:00:07 MSK

В bash есть автодополнение команд — первое, что в глаза бросаеться.

Deleted
( 11.10.15 17:05:51 MSK )

Ребята не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте тему и забудьте что тут писалось. Я вполне понимаю что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых — стоп. Остальные просто не найдут.

zolden ★★★★★
( 11.10.15 18:19:20 MSK )
Ответ на: комментарий от orionit 11.10.15 17:00:07 MSK

Спасибо за ответ все понятно, но не могли бы вы привести пример отличия bash от sh. p.s Крохотный пример.

Вот некоторые крохотные примеры (список не ичерпывающий): https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html . Это то, что bash по умолчанию НЕ делает, но делает, если включить решим повышенной совместимости с POSIX.

proud_anon ★★★★★
( 11.10.15 18:34:10 MSK )
Последнее исправление: proud_anon 11.10.15 18:35:50 MSK (всего исправлений: 1)

Ответ на: комментарий от zolden 11.10.15 18:19:20 MSK

а откуда пошла эта копипаста?

anonymous
( 11.10.15 18:40:23 MSK )
Ответ на: комментарий от zolden 11.10.15 18:19:20 MSK

Предприимчивые молодые люди, стоит интересоваться этой темой. Вы молодые, здоровые, умные. Это то что надо. Это яхты и виллы. Сюда нужно вливаться незамедлительно. Серьезно, любой из вас будет счастлив от такого. Это лучше чем сидеть на жопе и создавать треды про ЕОТ. Я вполне понимаю что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь — самое опасное в жизни — прожить ее, не заметив, как она прошла, будучи серой мышью. Остальные просто не будут такими умными чтобы сделать все чисто.

Kilte ★★★★★
( 11.10.15 18:43:42 MSK )
Ответ на: комментарий от Bfgeshka 11.10.15 17:05:00 MSK

супер классное оформление

Vlad-76 ★★★★
( 11.10.15 18:45:56 MSK )

В общем смысле shell — командная строка, либо доступ к командной строке ( «есть шел на сервере», «дать доступ к shell» )

bash — один из интерпретаторов командной строки. Приложение, которое запускается, когда пользователь получает доступ к shell

В узком смысле, sh ( bourne shell ) — один из первых интерпретаторов командной строки. Стандарт; реализации sh есть во всех unix без исключения ( поправьте меня ). Возможности bash шире, чем у sh ( больше команд, богаче синтаксис ). bash поддерживает все команды sh

router ★★★★★
( 11.10.15 18:48:04 MSK )
Ответ на: комментарий от anonymous 11.10.15 18:40:23 MSK

ИМХО, какая-то вариация обращения жирика к бушу. На лурке было

router ★★★★★
( 11.10.15 18:49:26 MSK )

Всем спасибо за ответы, понял в чем разница между bash и sh.

orionit
( 11.10.15 20:03:54 MSK ) автор топика
Ответ на: комментарий от Deleted 11.10.15 17:05:51 MSK