Когда важно писать переносимые сценарии?

Большая часть кода, который я пишу, написана на PHP. Я недавно начал изучать сценарии оболочки. Большинство ресурсов и учебных пособий, с которыми я сталкивался, относятся к Bash. Некоторые предупреждают о bashisms, а некоторые нет. Я много читал здесь и переполнение стека.

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

Вы не должны использовать <вставьте здесь bashism>. Это не портативный.

Это происходит даже тогда, когда вопрос был помечен bash. Для меня это все равно, что сказать программисту PHP, что они не должны использовать код, новый в PHP 5, потому что его нельзя использовать с PHP 4. Или сказать кому-то, что они не должны писать что-то для Mac, потому что его нельзя использовать на винде.

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

Если я использую #!/bin/bashв качестве шебанга, почему я не должен использовать bashisms? Я начинаю , чтобы получить впечатление , что некоторые люди просто любят Баш bashisms (каламбур) только ради этого.

Люди часто используют bashи shellвзаимозаменяемо - вероятно, из-за того, что bash является оболочкой по умолчанию во многих системах. Таким образом, я могу понять добавление комментария, предупреждающего, что код использует bashisms, но я не понимаю, что их использование неправильно .

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

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

Итак, когда важно писать переносимые сценарии?

Например,

какие типы сценариев должны быть максимально переносимыми?
Насколько распространены системы, в которых не установлен Bash?
если в системе установлен Bash, будет ли у него также версия GNU find и другие утилиты?

— toxalot
источник

Я проголосовал за этот вопрос и ответил на него, но чем больше я об этом думаю, тем более последние 2 вопроса подходят для сайта. Другие «в первую очередь основаны на мнении».

— Иордания

В этом вопросе также есть мета-аспект: хотя это может не помочь при первоначальном ответе на вопрос, комментарии типа «это непереносимо» могут быть очень полезны для других читателей, спотыкающихся через вопрос / ответ месяцы или годы спустя.

— Bananguin

@Bananguin Комментарии, говорящие "это не портативно", не беспокоят меня. Это просто к вашему сведению. Я сделал эти типы комментариев сам. Меня беспокоит «Ты не должен использовать ...». Это означает, что с ответом что-то не так. Это было бы допустимо, если бы в качестве ответа рекомендовался, например, устаревший код. Так что мне стало интересно, что не так с Башом.

— toxalot

+1. Особенно, когда в вопросе есть bashтолько один тег, кто-то комментирует: «Это башизм, а не переносимость». Когда я отвечаю на вопрос, помеченный тегами C, мне все равно, переносим он Javaили нет.

— PP

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

— Мартин Турной

Ответы:

Как член этого сообщества, я не часто вижу людей, игнорирующих bashisms для вещей, которые нацелены на bash. Говоря о переносимости, GNUisms гораздо хуже, чем bashisms. Пока вы используете bashдля своего шебанга, вы можете ожидать, что скрипт будет выполнен с использованием bash. Тем не менее, вы не можете гарантировать версию, если вы не проверите явно. Bash версии 4 принес некоторые полезные функции, такие как ассоциативные массивы, но Bash v3 все еще широко используется в OS X и RHEL 5.

какие типы сценариев должны быть максимально переносимыми?

Это больше о ваших потребностях и о том, что вы решите поддержать как разработчик. Если вы пишете скрипт установки для приложения, которое поддерживает все типы * NIX, переносимость будет очень важна.

Насколько распространены системы, в которых не установлен Bash?

FreeBSD и Solaris 10 являются примерами систем, которые не поставляются с установленной по умолчанию bash. Большинство систем Linux будет иметь его, за исключением встроенных систем.

если в системе установлен Bash, будет ли у него также версия GNU find и другие утилиты?

Нет, и это реальная проблема с мобильностью. Если важна переносимость, вы должны использовать только те команды оболочки, которые определены стандартом POSIX. Утилиты GNU могут быть установлены в не-GNU системах, таких как FreeBSD, но они вряд ли будут первыми в PATH, и вы не можете полагаться на эти инструменты, которые будут установлены.

— jordanm
источник

Я думаю, что это больше на SO, чем здесь, где я часто вижу людей, игнорирующих bashisms . Я просто знаю, что заметил это достаточно часто, чтобы расстроить меня и побудить меня задать этот вопрос.

— Токсалот

Так что, если утилиты GNU установлены, но не сначала в PATH, есть ли способ вызвать их конкретно? Иначе зачем их вообще устанавливать?

— Токсалот

@toxalot: двоичные файлы и сценарии вызываются явно с использованием абсолютных путей.

— Bananguin

@Bananguin Итак, если у кого-то были установлены утилиты Bash и GNU (но не в PATH), они могли бы использовать сценарий, если редактировали его, чтобы использовать абсолютные пути для findлюбых других утилит, специфичных для GNU, которые я использовал? Очевидно, что это не будет удобно для сценария установщика. Но я думаю просто поместить что-то на GitHub, чтобы другие могли его захватить, если они того пожелают. Мне все равно, что он не переносим для каждой системы. Я просто не хочу, чтобы это было бесполезно во многих системах.

— toxalot

@toxalot: да, это может сработать. если вы поместите что-то вроде FIND=/opt/gnu/dispicable/bin/findв начале вашего сценария, а затем используете ${FIND}вместо этого findв своем сценарии, вы даете людям одно (!) место, чтобы указать их пути установки и заставить ваш сценарий использовать правильные инструменты.

— Bananguin

Итак, когда важно писать переносимые сценарии?

какие типы сценариев должны быть максимально переносимыми?

Когда вы используете их для своей рабочей среды и работаете (или могли бы работать в будущем) на разных машинах - И вам не нужно переписывать свои инструменты перед тем, как приступить к работе.

например: мусорный скрипт / rmзамена

Марк Стюарт:

... для моего инструментария по устранению неполадок я предполагаю, что у меня будут только оболочки vi и Korn. И я пытаюсь использовать команды, которые работают на большинстве разновидностей Unix.

— user3082
источник

Мне нравятся некоторые изящные "Bash-isms", но для моего инструментария по устранению неполадок я предполагаю, что у меня будут только оболочки vi и Korn. И я пытаюсь использовать команды, которые работают на большинстве разновидностей Unix. Таким образом, я готов выполнить сортировку в больной системе, не беспокоясь о том, как ведет себя команда ps, есть ли там Bash, Perl или PHP, или где они находятся.

— Марк Стюарт