В чем проблема с башизмами? [закрыто]
Под «Bashism» я имею в виду синтаксис оболочки, который понимается только оболочкой bash, а не другими оболочками.
Если вы напишете сценарий, который запускается только в средах, где существует / bin / bash , то я думаю, что избегать башизма бесполезно и напрасно тратить время, но, возможно, я что-то упускаю.
Какая польза от написания сценариев более сложным способом, когда есть более простое решение, если вам разрешено использовать функцию, которая доступна только в Bash?
Возникает следующий вопрос: Есть ли конкретные данные о скорости bash и dash?
Я опубликовал свой вывод здесь: https://github.com/guettli/programming-guidelines/blob/master/README.rst#portable- shell-scripts
2 ответа
Во-первых, мобильность. Ничто неправильно, если Вы являетесь уверенными удар (и предпочтительно то же или более новыми) версия будет везде, Вы используете сценарий. Если Вы - разработчик или системный администратор, который ожидает, что программное обеспечение будет использоваться на подобной Unix ОС помимо Ubuntu, и они могут или не могут иметь bash, затем bashisms не будет понят под /bin/sh.
Во-вторых, соответствие POSIX. Если Вы пишете и сценарии отправки, которые будут включены как часть ОС или проекта, они часто требовали, чтобы быть в /bin/sh синтаксис, который является в основном, каков стандарт POSIX. /bin/sh часто предпочитается по причинам производительности, поэтому если Вы нуждаетесь в скорости в сценариях оболочки, bashisms и поэтому колотите, возможно, что-то для предотвращения.
Короче говоря, bashisms не плохи. Это действительно зависит от контекста, для которого Вы пишете сценарий. Если это - уверенность, что удар будет доступен, и не очень устареет, то всеми средствами используют функции - они там по причине.
Ничто, как таковое, если Вы знаете, что используете определенную для Bash функцию, и не забывают использовать #!/bin/bash hashbang вместо принятия /bin/sh Bash.
В Ubuntu (и Debian) "bashisms" в #!/bin/sh сценарии являются главным образом проблемой когда значение по умолчанию /bin/sh был изменен для Подчеркивания штриховой линией вместо Bash, как это было ранее (см. DashAsBinSh в Ubuntu Wiki). Все сценарии, работающие с /bin/sh должен был быть проверен на bashisms и зафиксирован для использования стандартных функций, поддерживавших Тире. Изменение не было о доступности Bash (это все еще Essential пакет, поэтому всегда устанавливаемый), но о скорости: прежде systemd, процесс начальной загрузки породил многочисленные сценарии оболочки, и изменение оболочки по умолчанию к более быстрой на самом деле оказало влияние.
В других системах, /bin/sh мог бы все еще быть Bash, позволив случайно использовать определенные для Bash функции в сценариях, отмеченных с #!/bin/sh. Они не работали бы непосредственно в системе где sh не Bash. Затем существуют системы, которые не имеют Bash вообще. Встроенные системы часто только сделали, чтобы Busybox окружил. Unixen не-Linux не может иметь Bash, хотя у них часто есть некоторая версия ksh, который является, куда многие функции Bash прибывают из. Они не 1:1 совместимы, как бы то ни было.
Некоторые нестандартные функции в Bash очень полезны (например, массивы, части подстроки (${var:n:m}), текстовая замена (${var/foo/bar})), поэтому если они делают Ваш сценарий легче записать, любой ценой Bash использования.
Тем не менее существуют некоторые bashisms, которые имеют прямые стандартные эквиваленты, означая, что существует минимальная причина использовать нестандартный вариант. Некоторые, которые приходят на ум:
-
==оператор в[ .. ]нестандартно, но эквивалентен стандарту=оператор function f { ... }иf() { ... }эквивалентны в Bash, но первый нестандартен. (Это от ksh, где существует различие.)$((--n))нестандартно, но может быть заменен$((n=n-1))- В простых случаях
[[ ... ]]может быть заменен стандартом[ .. ]