В чем преимущество сценария оболочки по сравнению с интерпретируемыми языками программирования? [закрыто]

(Я не уверен, что это уместный вопрос здесь)

Скрипты оболочки, как написанные в bash, могут делать много вещей. Они могут вызывать программы Unix, направлять их вывод, перенаправлять ввод / вывод из / в файлы, управлять потоком, проверять, существует ли файл и т. Д.

Но современный язык программирования, например, pythonи ruby, также может делать эти вещи. И они (я думаю) более читабельны и ремонтопригодны.

bashпользуется широким распространением. Но во многих дистрибутивах также установлен pythonинтерпретатор.

Так в чем же преимущество оболочки скрипта? Если бы я мог написать python, rubyили perl, стоит ли учиться bash?

Оболочки имеют специальные функции для работы с файлами и передачи данных из одной программы в другую (при условии, что данные являются текстовыми). Для этих задач сценарии оболочки могут быть менее громоздкими, чем язык сценариев, такой как Python.

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

Вот, например, скрипт bash, который перемещает все файлы PNG из текущего каталога в указанный каталог.

#!/usr/bin/sh
mv *.png $1

Вот версия Python.

#!/usr/bin/python
import sys, shutil, glob
for filename in glob.iglob("./*.png"):
    shutil.move(filename, sys.argv[1])

Вы заметите:

• Скрипт bash занимает третье место по сравнению с Python, если считать строки (исключая строку shebang) - еще меньше по количеству символов
• Сценарий Python требует импорта трех библиотек, в то время как все, что вам нужно для этой задачи, изначально доступно в bash
• Скрипт Python требует явного цикла для перемещения файлов, тогда как это является частью семантики mvкоманды в bash
• Скрипт bash может работать быстрее - вы, вероятно, вызовете его из bash, и вы можете использовать его sourceдля запуска в том же экземпляре оболочки
• glob.iglob("./*.png") довольно глоток просто сказать *.png

Если вы хотите написать основную конвейерную операцию на Python, вы будете поражены многословием. (Конечно, некоторые вещи, такие как передача по каналу grep, могут быть заменены кодом Python, а не использованием внешней программы, поэтому вам часто не нужно передавать так много.)

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

Я сделал это в bash, потому что это было частью нашей системы сборки, которая уже была написана на bash. Это было точно так же сложно, как вы думаете. Написание на Python заняло бы намного меньше времени и, вероятно, было бы более понятным.

Вкратце: разные языки предназначены для разных задач; выберите язык, который вам больше всего подходит для выполнения поставленной задачи.

Существующие ответы также действительны, но есть одна причина, о которой еще никто не упомянул: потому что она будет там.

Любая данная установка * nix выполняется с некоторым набором дополнительных пакетов, которые могут загружаться или не загружаться, и не все системы будут иметь Python, Perl или Ruby. Но если ожидается, что система вообще будет иметь какие-либо интерактивные возможности, она будет иметь оболочку. Это означает, что сценарии оболочки будут работать в системах от серверов до рабочих столов программистов и секретарских рабочих столов тонких клиентов и встраиваемых устройств в любой системе, поддерживающей доступную для записи файловую систему и командную строку bash.

Для тех, кто работает только в согласованной серверной среде, это то, что можно воспринимать как должное, и это не так важно. Для тех, кто работает в более разнообразной среде, это не следует упускать из виду.

На значительную часть вашего вопроса ответ здесь:

Почему языки сценариев (например, Perl, Python, Ruby) не подходят в качестве языков оболочки?

Вот выдержка из моего ответа на этот вопрос :

Есть несколько различий, о которых я могу думать; просто мысли здесь, в произвольном порядке

1. Python & Co. разработаны, чтобы быть хорошими в сценарии. Bash & Co. предназначены только для хорошо сценариев, с абсолютно никаких компромиссов. IOW: Python разработан, чтобы быть хорошим как в сценариях, так и в сценариях, а Bash заботится только о сценариях.

2. Bash & Co. нетипизированы, Python & Co. строго типизированы, что означает, что число 123, строка 123и файл 123совершенно разные. Однако они не имеют статической типизации, что означает, что им нужно иметь разные литералы для них, чтобы их можно было разделить. Пример:

   • Рубин: 123(число), Баш:123
   • Рубин: '123'(строка), Баш:123
   • Рубин: /123/(регулярное выражение), Баш:123
   • Рубин: File.open('123')(файл), Баш:123
   • Ruby: IO.open('123')(дескриптор файла), Bash:123
   • Рубин: URI.parse('123')(URI), Баш:123
   • Рубин: `123`(команда), Баш:123

3. Python & Co. предназначены для расширения до 10000, 100000, может быть , даже 1000000 отраслевых программ, Bash & Co. предназначена для масштабирования вниз до 10 символа программ.

4. В Bash & Co. файлы, каталоги, файловые дескрипторы, процессы являются первоклассными объектами, в Python первоклассными являются только объекты Python, если вы хотите манипулировать файлами, каталогами и т. Д., Вы должны обернуть их в Сначала объект Python.

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

У меня такое чувство, что попытка решить эти вопросы, используя функции или DSL на языке программирования общего назначения, не работает. По крайней мере, мне еще предстоит увидеть убедительную реализацию этого. Существует RuSH (оболочка Ruby), которая пытается реализовать оболочку в Ruby, есть rush, который является внутренним DSL для программирования оболочки в Ruby, есть Hotwire, представляющая собой оболочку Python, но IMO ни одна из них даже близко не подходит конкурировать с Bash, Zsh, рыбой и друзьями.

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

С другой стороны, если ваша задача программирования больше нуждается в управляющих структурах (если / то / еще), итеративных структурах (циклы), вводе / выводе базы данных и файлов и т. Д., То она, вероятно, лучше подходит для более способных язык программирования, чем сценарий оболочки.

Я думаю, что хорошее правило:

automatingSimpleTask ? shellScript() : programmingLanguage();

Хотя вы можете запускать программы из python / ruby ​​/ любой другой программы, в оболочке все по-другому. Вам может понадобиться использовать API для запуска чего-либо - например, fork (). В сценарии оболочки программы ведут себя больше как функции на обычном языке программирования и могут быть выполнены, переданы по конвейеру и т. Д. С минимальными усилиями. Поток данных очень четкий, если использовать каналы.

Если вы абсолютно свободны в выборе языка программирования, который вы используете для определенных задач, вы, вероятно, можете почти полностью избежать изучения bash и выполнять все задачи программирования сценариев с помощью Perl, Python или Ruby. Иногда это может привести к более подробному решению, особенно в случае, когда вам просто нужен сценарий, вызывающий последовательность других инструментов Unix, но в более сложных случаях вы правы, эти современные языки сценариев дают вам больше возможностей для написания лучшего обслуживаемого кода (они также дают вам больше возможностей для написания запутанного кода, но это ваш выбор).

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

Сценарии оболочки - это интерпретируемый язык программирования. Вот несколько причин, по которым я решил писать скрипты на bash, а не на perl или python или каком-либо другом языке сценариев:

Работает везде : более сложные интерпретаторы могут быть не всегда доступны, например, при запуске системы или во встроенных системах. Bash доступен даже в busybox.

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

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

Если в программе 30 строк или меньше, я обычно пишу ее, используя сценарии оболочки. Если есть какие-либо сложные манипуляции или сложные или анализ для решения, я сделаю это с помощью Python или Perl.

Вы должны взглянуть на coffeescript. Их слова:

Под всеми этими неуклюжими скобками и точками с запятой в основе JavaScript всегда лежала великолепная объектная модель. CoffeeScript - это попытка раскрыть хорошие части JavaScript простым способом.

Золотое правило CoffeeScript гласит: «Это просто JavaScript».

Ну ... вот и ответ супер-новичка.

Как начинающий с самообучением в течение последних 6 месяцев, и немного пробовал C, C ++, Javascript и другие Bashscript в последние дни ... Я могу вам сказать:

Скрипты оболочки, как и написанные на bash, могут делать много вещей. Они могут вызывать программы Unix, направлять их вывод, перенаправлять ввод / вывод из / в файлы, управлять потоком, проверять, существует ли файл и т. Д.

и это не просто фантастика! ? циклы и переменные? Вот это да!

Python и Ruby, также могут делать эти вещи. И они (я думаю) более читабельны и ремонтопригодны.

Пожалуйста, скажите мне, где вы видите это? Я написал bashscript в gedit даже в geany, и я могу отформатировать (табы?), И я читаю свой код со скоростью света, используя bashscript для сравнения на других языках.

Есть ли у этих языков другие инструменты для поддержания порядка? Я знаю, что объектно-ориентированный сохранить много кода, но ... люди говорят, что bashscript тоже ОО! ВАУ 2! Это моя точка зрения здесь. Собираюсь:

преимущество shell скрипта

в этом вопросе: как сделать то, что может сделать эта чушь в perl, phyton или ruby? Это просто?

( bashdamnthing = xdotool )