Есть ли преимущество использования Bash над Perl или Python? [закрыто]

19

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

Проблема заключается в том, что я не нашел существенного преимущества использования Bash над чем-то вроде Perl или Python. Существуют ли различия в производительности или мощности между этими двумя? Я бы подумал, что Python / Perl будет более подходящим для мощности и эффективности.

    
задан ManAmongHippos 02.05.2011 в 17:12
источник

8 ответов

16

Приходят на ум два преимущества:

  • Простота: прямой доступ ко всем замечательным инструментам linux wc , ls , cat , grep , sed ... и т. д. Зачем постоянно использовать модуль subprocess python?
  • Я все больше люблю использовать gnu parallel , с помощью которого вы можете выполнить ваши сценарии bash параллельно. Например. с man-страницы, пакетно создавать большие пальцы всех jpg в каталоге параллельно:

    ls *.jpg | parallel convert -geometry 120 {} thumb_{}

Кстати, у меня обычно есть некоторые вызовы python в моих сценариях bash (например, для построения). Используйте все, что лучше для задачи!

    
ответ дан Sebastian 02.05.2011 в 17:21
6

Скрипты Perl обычно (если не в 100% случаев) быстрее, чем bash.

Обсуждение этого вопроса: Perl vs Bash

    
ответ дан Mario Peshev 02.05.2011 в 17:16
4

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

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

  2. Правило «WTF за минуту». У каждого свой предел, а у меня довольно мало. Как только я доберусь до 3 WTF / мин, я ищу в другом месте.

Что касается «обтекания» на языках сценариев, таких как Perl и Python, я считаю, что мне почти никогда не нужно это делать, fwiw (отказ от ответственности: я кодирую почти 100% в Python). У модулей Python os и shutil есть большая часть того, что мне нужно в большинстве случаев, и есть встроенные модули для обработки tarfiles, gzip-файлов, zip-файлов и т. Д. Существует модуль glob, модуль fnmatch ... есть много там. Если вы сталкиваетесь с чем-то, что вам нужно распараллелить, то отступьте ваш код на уровень, поместите его в метод «run ()», поместите это в класс, который расширяет либо threading.Thread, либо многопроцессорность. Process, создайте экземпляр так, как многие из них вы хотите, называя «start ()» на каждом из них. Менее 5 минут, чтобы выполнить параллельное выполнение в целом.

Удачи. Надеюсь это поможет.     

ответ дан jonesy 02.05.2011 в 19:16
  • Я согласен, за исключением того, что мой личный предел для переключения с оболочки на Perl составляет 10-20 строк. –  reinierpost 03.05.2011 в 10:50
  • Оболочка Bourne (игнорируя bash - обычно вам не приходится прибегать к расширениям bash для написания сценариев оболочки), не было «взломано» так много, чтобы быть языком сценариев - это, вероятно, 30 лет, а основной функции программирования, такие как циклы, условия и функции, были с самого начала. –  ijw 07.05.2011 в 14:16
4

Для больших проектов используется язык Perl.

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

Плюс бывают случаи, когда зная, что колодец хорошо может спасти ваш бекон (на взломанной системе, где вы не можете запускать какие-либо новые процессы или если /usr/bin и /usr/local/bin не смонтированы).     

ответ дан daotoad 02.05.2011 в 19:40
4

Преимущество в том, что оно есть прямо здесь. Если вы не используете Python (или Perl) в качестве оболочки, писать сценарий для выполнения простого цикла - это куча дополнительной работы.

Короче говоря, простые скрипты, которые вызывают другие программы, я буду использовать Bash. Если я хочу сохранить вывод, то шансы хорошие, что я буду торговать с Python.

Например:

for file in *; do process $file ; done

где process - это программа, которую я хочу запустить для каждого файла, или ...

while true; do program_with_a_tendency_to_fail ; done

Выполнение любого из них в Python или Perl является излишним.

Для написания программы, которую я ожидаю поддерживать и использовать с течением времени, Bash редко является подходящим инструментом для работы. В частности, поскольку большинство современных Unices поставляются как с Perl, так и с Python.

    
ответ дан nmichaels 02.05.2011 в 17:18
  • попробуйте это заменить ваш первый пример (меньше набрав, более параллельный): ls | параллельный процесс –  Sebastian 02.05.2011 в 17:35
  • @Sebastian: Волшебный! Хотя я думаю, что параллельный процесс - ближе. –  nmichaels 02.05.2011 в 18:05
  • ls | Процесс xargs также будет работать так же, но все эти методы имеют ошибку: они не работают с именами файлов с пробелами или переводами строк. Вы хотите: для f в *; выполните процесс «$ f»; сделанный –  ijw 02.05.2011 в 21:17
  • @ijw: Ой, ты прав. Исправлена. –  nmichaels 02.05.2011 в 22:20
  • @nmichaels: вы используете pexec. Чтобы попробовать gnu parallel, следуйте ссылке в моем комментарии выше. PS: альтернативным синтаксисом для первого примера с параллельной gnu будет: параллельный процесс ::: * (немного ближе к pexec) –  Sebastian 03.05.2011 в 10:47
Показать остальные комментарии
3

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

    
ответ дан Sven Marnach 02.05.2011 в 17:16
  • Каждая машина Unix поставляется с Perl. –  tchrist 03.05.2011 в 14:55
  • @tchrist: В общности вы заявили об этом, это просто неправильно. –  Sven Marnach 03.05.2011 в 14:57
  • Назовите свои исключения. –  tchrist 03.05.2011 в 20:34
  • Например, при высокопроизводительных вычислениях вы обычно можете полагаться на доступность Perl на передних узлах, но не обязательно на вычислительных узлах. И не сложно настроить Linux-сервер без Perl. –  Sven Marnach 04.05.2011 в 13:01
2

Если вы хотите выполнить программы, установленные на машине, ничто не сравнится с bash. Вы всегда можете сделать системный вызов с Perl или Python, но я считаю, что это неприятность для чтения возвращаемых значений и т. Д.

И поскольку вы знаете, что он будет работать практически везде в течение всего времени ...

    
ответ дан drysdam 02.05.2011 в 17:18
  • Я не знал, что Python поддерживает syscall, поскольку эти примеры на Perl показывают, что Perl делает: syscall (& SYS_gettimeofday, $ tv, undef)> = 0 или syscall (& SYS_setgroups, scalar @newgids, pack ("i *", @newgids)) –  tchrist 03.05.2011 в 20:35
  • С помощью «системного» вызова я имел в виду «в оболочку». Не буквальные системные вызовы. Я не знал, что Perl может это сделать. –  drysdam 03.05.2011 в 21:05
  • Я вижу, как обстреливает и делает сценой как очень разные вещи. Один из них просто вызывает некоторую программу на уровне пользователя, такую ​​как оболочка, в то время как другие ловушки прямо в ядро ​​без каких-либо проблем или суеты. Первый обязательно использует много системных вызовов; второй, обязательно ровно один. –  tchrist 03.05.2011 в 22:02
  • Я согласен, они очень разные. Но поскольку я не знал, что вы можете сделать реальный системный вызов от Perl, я использовал «системный вызов» в том смысле, что он часто используется из скриптов: для обозначения команды оболочки. –  drysdam 03.05.2011 в 23:29
  • Если вы вызываете системную функцию, вы обстреливаете, не создавая системный вызов. Конечно, вы можете сделать syscalls из Perl: в Perl все возможно, но не все это целесообразно. ☺ –  tchrist 04.05.2011 в 01:50
1

Преимущество сценариев оболочки заключается в том, что он присутствует в глобальном масштабе на * ix-блоках и имеет относительно стабильный набор основных функций, на которые можно положиться, чтобы работать везде. С Perl и Python вам нужно беспокоиться о том, доступны ли они, и если да, какая версия, так как на протяжении всей их жизни существуют значительные синтаксические несовместимости. (Особенно, если вы включили Python 3 и Perl 6.)

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

    
ответ дан bobince 02.05.2011 в 17:21
  • Perl 6 установлен как другой исполняемый файл, поэтому вы можете использовать Perl 5 в любом случае. –  Alexandr Ciornii 03.05.2011 в 10:26