Какая оболочка является наиболее переносимой и какие передовые методы следует использовать?

Ваши сценарии bashдолжны работать на любой машине с установленной оболочкой bash, если только вы не используете функции bash, слишком новые для версии оболочки в другой системе, например, пытаясь используйте ссылки на имена (declare -n), ассоциативные массивы(declare -A)или формат %(...)Tprintf(или любой из множества других вещей )со значением по умолчанию bashв macOS (, которое является древним; просто установите более новый bashс Homebrew в этом случае ). Ваши сценарии также могут дать сбой, если они используют внешние инструменты, недоступные в какой-либо другой системе, или функции инструментов, которые могут быть не реализованы или реализованы по-другому.

Наиболее переносимым языком оболочки в системах POSIX является оболочка sh. Это описано здесь:https://pubs.opengroup.org/onlinepubs/9699919799/idx/shell.html

Оболочка bash(и другие )реализуют shс расширениями. Некоторые оболочки, такие как fishили zsh, даже не пытаются быть shоболочками (, но zshобеспечивают степень «sh- эмуляции» через --emulate sh), в то время как оболочки, подобныеdashпытается быть более чистым по отношению к стандарту POSIX sh(, но все же с некоторыми расширениями ).

Как правило, аспекты оболочки, относящиеся к синтаксису и встроенным функциям , должны быть «переносимыми», если сценарий всегда выполняется в одной и той же оболочке (и версии. оболочки, в некоторой степени ), даже если эта оболочка является оболочкой fish. Это тот же тип «переносимости», что и у сценариев Python, Perl и Ruby. Однако всегда должна быть доступна оболочка sh(, обычно устанавливаемая как /bin/sh), которая обычно bash,dashили kshработают в каком-то «режиме совместимости».

Наиболее переносимыми утилитами в системе POSIX являются утилиты POSIX. Они описаны здесь:https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html

Утилиты GNU, описанные в coreutils, реализуют утилиты POSIX (, что, как указывает пользователь schily в комментариях , не означает, что они совместимы с POSIX-), а затем расширяет их функциями, которые в основном предназначены для удобства. Это справедливо и для соответствующих утилит в других Unix-системах. Также обратите внимание, что пакет GNU coreutilsдля Linux не содержит всех утилит, указанных в POSIX, и такие утилиты, как find, sed, awkи другие, которые являются утилитами POSIX, упакованы отдельно.

До тех пор, пока вы пользуетесь POSIX-утилитами и используете их POSIX-поведение (с точки зрения параметров и т. д. ), в скриптах, использующих синтаксис POSIX sh, вы, скорее всего, будете «в основном переносимыми». в большинстве систем Unix. Но также обратите внимание, что существуют не -утилиты POSIX и не -расширения POSIX для утилит POSIX, которые по-прежнему достаточно переносимы, потому что они обычно реализуются. Примерами распространенных утилит, отличных от -POSIX, являются pkill, tarи gzip. Примерами не -расширений POSIX для утилит POSIX, которые обычно можно найти, являются предикат -inamefindи тот факт, что sedчасто можно заставить понять расширенные регулярные выражения, используя -E.

Вы узнаете, какие расширения в реализациях каких инструментов, работающих на какой Unices, как себя ведут, протестировав самостоятельно (на виртуальных машинах, например ), и прочитав вопросы и ответы на этом сайте. Например, Как я могу добиться переносимости с помощью sed -i (в -редактирование места )?

Также обратите внимание, что бывают случаи, когда стандарт POSIX оставляет поведение «неопределенным».это означает, что одна и та же утилита в двух разных системах Unix, использующая параметр POSIX, может вести себя по-разному. Пример этого можно найти здесь в Почему в разрешении отказано при обновлении символической ссылки на новую цель с разрешениями в порядке?

Недостаток попыток написать чистый код оболочки POSIX заключается в том, что вы упускаете некоторые действительно полезные функции. Однажды я попытался написать эквивалентные POSIX тесты для find, для которых тестируют предикаты GNU -readable, что было непросто, и попытка сигнализировать процесс по имени, используя psи grepвместо pkill, является тема слишком много вопросов на этом сайте. Точно так же, пытаясь «оставаться POSIX», вам нужно будет держаться подальше от действительно полезных вещей, таких как perl, и вы не сможете выполнять многие административные задачи переносимым образом (, добавляя пользователей, управлять резервными копиями, передавать файлы между системами и т. д.)

В целом я предпочитаю прагматичный подход к выполнению задач, понимая при этом, что мой код, возможно, придется модифицировать для поддержки других систем позже (, если он когда-либо будет использоваться в других системах ), а не пуристский подход. Это не мешает мне писать сценарии, которые, как я знаю, будут иметь как можно меньше проблем с переносимостью (. Я бы не стал везде использовать непереносимую семантику ). Но это мое личное мнение.