Я вижу два типа используемого кода:
#!/usr/bin/sh
а также:
#!/user/bin/bash
Я искал это онлайн, и мнения сильно различаются. Объяснения, которые я видел на большинстве веб-сайтов, говорят, что sh старше bash и разницы нет.
Кто-нибудь знает разницу между этими? Можете ли вы дать мне практический пример, когда использовать один над другим?
bash является надмножеством sh т.е. все, что вы можете сделать в sh вы можете сделать в bash .
Bash имеет больше возможностей (ветвление, встроенные функции, массивы), что облегчает написание скрипта. Некоторые более поздние * nix'ы имеют /bin/sh как ссылку на /bin/bash
Для полного объяснения того, что вот учебник
Традиционно, /bin /sh был бы оригинальной оболочкой Bourne, которая не имеет истории или редактирования в командной строке, а также не контролирует работу.
В течение последних 15 лет в большинстве Unix-систем была установлена оболочка POSIX, или, по крайней мере, ksh или bash (которые очень похожи на POSIX), но все еще имеют более ограниченную оболочку в /bin /sh
Причина этого в том, что старые сценарии оболочки, которые ожидают старшую команду sh будут работать.
Так как такие символы, как { , } и ! имеют особое значение для bash, возможно, что старый сценарий оболочки, использующий эти символы (не экранируя их), может потерпеть неудачу.
(Оболочка Борна взяла бы !!{1,2} буквально, тогда как bash интерпретирует это как повтор предыдущей команды (!!) с последующим расширением).
В Linux команда sh почти всегда представляет собой ссылку на bash со всеми теми же функциями.
sh может означать либо оболочку Bourne, либо /bin /sh, которая является другой (POSIX-совместимой) оболочкой на большинстве современных платформ. "Оболочка POSIX" - это абстрактная оболочка, определенная POSIX, которая реализуется с помощью bash в режиме POSIX или ksh или dash по умолчанию. /bin /sh иногда также называют оболочкой POSIX, потому что это оболочка, которая соответствует POSIX на большинстве платформ. Оригинальные оболочки Bourne не являются оболочками POSIX.
У bashref есть список различий между оболочками bash и Bourne. man bash есть список изменений, когда bash вызывается в режиме POSIX.
/bin/sh не является символической ссылкой или жесткой ссылкой в OS X, но он почти такого же размера, как /bin/bash:
$ ls -li /bin/{ba,}sh
29631757 -r-xr-xr-x 1 root wheel 1333920 Jul 26 01:52 /bin/bash
29631758 -r-xr-xr-x 1 root wheel 1334000 Jul 26 01:52 /bin/sh
Если bash вызывается с именем sh, он пытается максимально близко имитировать поведение при запуске исторических версий sh, при этом также соответствует стандарту POSIX.
В остальном мимикрирование снарядов Борна довольно ограничено. bash +B (Bourne) фактически отключил бы такие функции, как расширение скобок.
$ sh
$ echo {a,b}
a b
$ echo $BASH_VERSION
3.2.48(1)-release
$ bash +B
$ echo {a,b}
{a,b}
Но даже если вы отключите режим POSIX, echo ведет себя как echo -e по умолчанию:
$ sh
$ shopt -uo posix
$ echo '1\b2'
2
/bin/sh - черта в Ubuntu, поэтому некоторые ошибки работают с /bin/sh в OS X, но не в Ubuntu.
Если вы действительно хотите писать сценарии для (что-то вроде) оригинальных оболочек Борна, вы можете использовать #!/usr/bin/env bash +B вместо этого.
Я думаю, что проще написать сценарии для bash, чем избегать функций, которые не являются частью спецификаций POSIX или оболочек Bourne, или проверять все с помощью других оболочек.
Во многих системах, в частности в Solaris, bash динамически связан, а sh статически связан. Это может представлять угрозу безопасности, по этой причине пользователь root должен использовать только /bin /sh в качестве оболочки (если вам когда-либо понадобится войти в систему как root).
На самом деле, даже если /bin /sh может быть ссылкой на /bin /bash, при запуске как sh он ведет себя по-другому. Из справочной страницы bash:
Если bash вызывается с именем sh, он пытается максимально близко имитировать поведение при запуске исторических версий sh, при этом также соответствует стандарту POSIX.
Так как sh пытается подражать историческому поведению sh. Как bash , он старается быть максимально полезным, как интерактивная оболочка входа в систему.