Рекомендуется использовать zsh вместо скриптов bash? [закрыто]

Можно ли предположить, что достаточно людей zshустановили для запуска сценариев с

#!/usr/bin/env zsh

как шебанг?

Или это сделает мои сценарии неработоспособными на слишком многих системах?

Пояснение: меня интересуют программы / скрипты, которые конечный пользователь может захотеть запустить (например, в Ubuntu, Debian, SUSE, Arch & c.)

Для мобильности нет. Хотя он zshможет быть скомпилирован на любом Unix или Unix-подобном и даже Windows, по крайней мере, через Cygwin, и упакован для большинства Open Source Unix-подобных и нескольких коммерческих, он обычно не включается в установку по умолчанию.

bashна другом конце установлен в системах GNU (как bashи оболочка проекта GNU), таких как подавляющее большинство не встроенных систем на основе Linux, а иногда и в системах без GNU, таких как Apple OS / X. В коммерческой стороне Unix оболочка Korn (вариант AT & T, хотя и более того ksh88) является нормой и то и другое bashи zshнаходится в дополнительных пакетах. На BSDs, предпочтительная интерактивная оболочка часто в tcshто время как shна основе либо Almquist оболочки или pdkshи bashили zshнеобходимости , а также для установки в качестве дополнительных пакетов.

zshпо умолчанию устанавливается в Apple OS / X. Он даже был /bin/shтам. Его можно найти по умолчанию в некоторых дистрибутивах Linux, таких как SysRescCD, Grml, Gobolinux и, возможно, в других, но я не думаю, что это один из основных.

Например bash, есть вопрос об установленной версии и, как следствие, о доступных функциях. Например, нередко находить системы с bash3или zsh3. Кроме того, нет гарантии, что сценарий, для которого вы сейчас пишете, zsh5будет работать, zsh6хотя bashон пытается поддерживать обратную совместимость.

Для сценариев мое мнение таково: используйте синтаксис оболочки POSIX, так как все Unices имеют по крайней мере одну вызванную оболочку sh(необязательно в /bin), способную интерпретировать этот синтаксис. Тогда вам не нужно беспокоиться о переносимости. И если этого синтаксиса недостаточно для вашей потребности, то, вероятно, вам нужно больше, чем оболочка.

Тогда ваши варианты:

• Perl, который является вездесущим (хотя, опять же, вам, возможно, придется ограничиться набором функций старых версий, и вы не сможете делать предположения относительно модулей Perl, установленных по умолчанию)
• Укажите интерпретатор и его версию (python 2.6 или выше, zsh 4 или выше, bash 4.2 или выше ...) в качестве зависимости для вашего сценария, либо путем создания пакета для каждой целевой системы, в котором указана зависимость, либо путем ее указания в файле README, поставляемом вместе с вашим сценарием или в виде комментариев в верхней части вашего сценария, или путем добавления нескольких строк в синтаксисе Bourne в начале сценария, который проверяет доступность запрошенного интерпретатора и выдает явную ошибку когда это не так, как этот скрипт требует Zsh 4.0 или выше .
• Поставьте переводчик вместе с вашим сценарием (остерегайтесь последствий лицензирования), что означает, что вам также нужен один пакет для каждой целевой ОС. Некоторые интерпретаторы упрощают задачу, предоставляя способ упаковки сценария и его интерпретатора в один исполняемый файл.
• Напишите это на скомпилированном языке. Опять же, один пакет на целевую систему.

Нет, ты не можешь. То, что гарантировано доступно /bin/sh, по сути, оригинальная оболочка Bourne. Почти все (обратите внимание на «почти»!) Установки Linux будут иметь bash, но в системах * BSD это происходит редко (у убеждения BSD есть серьезные опасения по поводу кода GPL, например bash). Я не знаю, что такое стандартная оболочка на Mac, но опять же, есть опасения по поводу GPL. То же самое для соляриса.

zsh - это нишевая оболочка, она не входит в стандартную установку Fedora (и я не верю, что она используется по умолчанию для любого крупного дистрибутива).

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

В то же время, если ваш сценарий предназначен для выполнения в вашей организации, и у вас есть соглашение, чтобы zsh на ваших компьютерах (например, тот же базовый AMI) и ваша задача имели явные преимущества от расширений, таких как расширенные средства выбора файлов или другие вещи из http: / /www.rayninfo.co.uk/tips/zshtips.html Я бы сказал, вперед!

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

Важный вопрос, на который нужно ответить перед разработкой сценария: « Почему важно, в какой оболочке выполняется сценарий? »

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

Например, bashоболочка поддерживает определенные расширения, которые не поддерживаются dashоболочкой Борна или чем-либо еще, на что /bin/shуказывает система пользователя.

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Feb 19  2014 /bin/sh -> dash

Попробуйте выполнить echo {1..10}с « /bin/shпо сравнению с», /bin/bashи вы получите очень разные результаты.

То же самое касается, zshкоторый, хотя и поддерживает большинство bashсинтаксиса, предлагает дополнительное расширение и синтаксис, который не поддерживается bashоболочкой. См. Эти таблицы сравнения оболочек для конкретных примеров.

Вы можете расширить свою потенциальную пользовательскую базу bash, придерживаясь сценариев, которые работают при вызове #!/bin/sh -u. Однако это вызывает еще один важный вопрос: « Чем жертвуют в обмен на большую мобильность? »

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

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

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

Помните, что если вы используете оболочку для чтения сценария оболочки («sh scriptname»), вместо того, чтобы выполнять его напрямую («./scriptname»), оболочка будет обрабатывать все комментарии в начале сценария оболочки как комментарии. В частности, комментарий, который указывает интерпретатор для использования при выполнении сценария («#! / Bin / sh -u»), будет игнорироваться, как и все параметры, перечисленные рядом с этим интерпретатором.

Таким образом, лучшее, что вы можете с этим сделать, - это сделать ваши скрипты переносимыми, пока они не принесут большой жертвы тому, как они функционируют.

Вы также можете увидеть соглашения по кодированию Bash - переполнение стека .

Единственное, что вы можете почти гарантировать, это то, что есть /bin/sh. Это может быть фактически статическая связанная оболочка или ссылка на другую оболочку. Эта другая оболочка обычно обнаруживает, что она называется sh и будет работать в режиме совместимости.

Обратите внимание почти на первое предложение.

Каждая система, подобная Unix, над которой я когда-либо работал, имела это. На многих из них также был установлен bash (но не на всех . Например, bash он не устанавливается по умолчанию на некоторых BSD. Некоторые дистрибутивы Linux поставляются с DASH , а не с оболочкой Debian Almquist.

То, что вы можете гарантировать, это ваши инструкции по установке. Вы можете добавить строку в файл README, указав, что требуется zsh. Если вы собираете пакет, вы можете пометить zsh как зависимость. Вы можете проверить это с помощью инструментов autoconf / automake. Вы можете проверить, есть ли zsh в сценарии установки (начните с / bin / sh и попробуйте найти zsh, если обнаружите продолжение. Если не отображается ошибка. Например, «Предупреждение: ZSH не установлен. Пожалуйста, прочтите файл инструкции по установке! ».)

Я уверен, что забыл еще несколько вариантов. Но ключевые моменты:

• Вы ничего не можете гарантировать, пока не проверите на это.
• Вы почти гарантированы, что / bin / sh присутствует, и что вы можете сделать некоторые проверки с этим.