Есть ли какое-либо использование для Bash, пишущего сценарий еще? [закрытый]

Вы можете получить настоящий бурнеш на свежем мясе (например, в Mac OS X / bin / sh не является настоящим бурнешем).

Как определить традиционную оболочку Борна? ... Простая проверка часто недокументированной, но характерной особенности: вы можете использовать циркумфлекс ^ (каретка) вместо | (трубка).

см .: http://www.in-ulm.de/~mascheck/bourne/

По моему опыту, Perl удовлетворяет примерно 99% всех потребностей, для которых может потребоваться сценарий оболочки. В качестве бонуса можно написать код, который работает под Windows без Cygwin. Если у меня нет возможности установить Perl на Windows, я могу использовать PAR::Packer или PerlApp для создания исполняемого файла. Python, Ruby и другие языки тоже должны работать так же хорошо.

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

Узнайте, как читать и устанавливать переменные. Как создавать и вызывать функции. Как создавать источники других файлов. Узнайте, как работает управление потоком данных.

И самое главное - научитесь читать man-страницы shell. Это может показаться смешным, но я на 100% серьезен - не беспокойтесь о том, чтобы впихнуть в свой мозг все детали shell-сценариев, вместо этого научитесь быстро и эффективно находить то, что вам нужно знать в man-странице. Если вы будете часто использовать shell-сценарии, то необходимая информация естественным образом закрепится в вашем мозгу.

Итак, да, базовый shell стоит изучить.

Bash (и оригинальный Bourne sh и множество производных) - с одной точки зрения - невероятно высокоуровневый язык. Там, где многие языки используют простые примитивы, примитивы оболочки представляют собой целые программы.

То, что это может быть не лучший язык для выражения ваших задач, не означает, что он мертв, умирает или даже умирает.

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

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

Кроме того, изучение Bash поможет понять, как на самом деле работает Unix и некоторые основные вещи - и как далеко мы продвинулись с такими инструментами, как Python.

Проще, наверное, нет. Я предпочитаю perl сценариям на bash во многих случаях. Однако у Bash есть одно преимущество, особенно в системах Linux: он практически гарантированно установлен. А если его нет, то будет установлен его во многом совместимый отец (sh), потому что почти все системные скрипты написаны для sh. Даже perl не настолько вездесущ, а он есть везде.

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

Тривиальный пример для перечисления $ PATH

Bash

#!/bin/sh
echo $PATH

Python

import os
print os.getenv("path")

Что ж, при написании с помощью bash вы можете напрямую использовать все возможные инструменты, которые есть в командной строке для вашего скрипта. На любом другом языке вам сначала нужно выполнить эту команду и получить какой-то результат и т. Д. Простой скрипт, который (например) получает список процессов, запускается через grep и получает какой-то результат, на других языках будет намного сложнее. Таким образом, bash по-прежнему остается хорошим инструментом для быстрого написания.

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

РЕДАКТИРОВАТЬ поиск в Google:

• исчерпывающий список хороших примеров
• Полезные советы и приемы bash
• 18 полезных скриптов для Web Devel.
• двухминутное кодирование на bash для улучшения использования git

Я также хотел бы упомянуть, что TextMate успешная программа для OS-X имеет внутри множество механизмов Bash.

Помимо того, что сказали другие, я хотел бы отметить, что, на мой взгляд, является главной причиной для изучения Bash: это (почти) стандартная оболочка Linux shell.

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

Умение управлять вводом-выводом, трубами и процессами, назначать и использовать переменные, а также делать хотя бы некоторые циклы и оценивать условия - обязательное условие, если вы хотите управлять системой Linux.

Я любитель Perl, но количество функций bash (или ksh), которые я использую и создаю ежедневно, довольно велико. . Для всего, что связано с этим, я напишу perl-скрипт, но для навигации по структуре каталогов и, в частности, для управления переменными среды bash / ksh / ... незаменимы.

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

Я сделал это, особенно для тяжелой работы с переменными пути. Но нет возможности сделать это в , только на Perl (или python, или ruby ​​... или C-коде, если на то пошло).

Многие сценарии запуска традиционно пишутся как сценарии оболочки, и, похоже, нет тенденции к отказу от них.

Shell-сценарии прекрасно подходят для запуска других процессов и склеивания их ввода/вывода вместе. Это та область, где другие языки сценариев не так мощны.

Помимо этого: даже если языки вроде Perl, Python и Ruby становятся все более и более вездесущими, единственный язык, который практически гарантированно есть в каждой unix-подобной системе - это bourne shell ('хотя и не обязательно в виде bash).

Реальная разница между bash и python заключается в том, что python - это язык сценариев общего назначения, в то время как bash - это просто способ последовательного запуска множества небольших (и часто очень быстрых) программ. Python может это делать, но он не оптимизирован для этого. Программы (sort, find, uniq, scp) могут выполнять очень сложные задачи очень просто, и bash позволяет этим задачам очень просто взаимодействовать с трубопроводами, промывая вывод в файлы или устройства и т.д.

Хотя Python может запускать те же программы, вам придется выполнять сценарии bash в сценарии python, чтобы добиться того же самого, и тогда вы застрянете и с python, и с bash. Оба варианта хороши сами по себе, но их сочетание ничего не улучшает IMHO.

Для многих задач bash может быть очень кратким. Код для поиска строки во всех файлах текущего каталога и печати этих строк:

В bash:

grep -ir "search_term" .

В Python:

for file in os.listdir('.'):
  file_content = open(file).readlines().split('\n')
  for line in file_content:
    if line.count("search_term") > 0:
      print file, ": ", line

Bash - это не только язык сценариев, но и оболочка.

Языки управления заданиями и оболочки
Основная статья: Shell script

Основной класс скриптовых языков вырос из автоматизации управления заданиями управления, которое связано с запуском и управление поведением системных программ. (В этом смысле можно рассматривать оболочки как потомков JCL, или языка управления заданиями, разработанного IBM, который использовался именно для этой цели.) Многие из этих языков интерпретаторы удваиваются как интерпретаторы командной строки интерпретаторы командной строки, такие как оболочка Unix или MS-DOS COMMAND.COM. Другие, такие как например, AppleScript, предлагают использовать англоязычные команды для создания сценариев. В сочетании с Mac OS X Cocoa фреймворками позволяет пользователю создавать целые приложения, используя AppleScript и объекты Cocoa.

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

В некоторых случаях сценарии оболочки работают намного лучше из-за более тесной интеграции с ОС.

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

Как уже упоминалось, инструменты GNU великолепны, и их проще всего использовать в оболочке. Это особенно удобно, если ваши данные уже представлены в виде простого текста в линейной или табличной форме. В качестве примера, на днях мне удалось создать сценарий для создания облака слов XHTML для любого текстового файла в 8 строках Bourne Shell, который даже менее мощный (но более широко поддерживаемый), чем Баш.

Чего я не понимаю, так это того, почему люди говорят bash , имея в виду любую bourne-shell совместимую оболочку.

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

И да, на сегодняшний день сценарии оболочки используются в большом количестве, поскольку оболочка всегда существует во всех unix-версиях прямо из коробки, в отличие от perl, python, csh, zsh, ksh (возможно?) И так далее. В большинстве случаев они только добавляют дополнительное удобство или другой синтаксис для таких конструкций, как циклы и тесты. В некоторых улучшены функции перенаправления.

В большинстве случаев я бы сказал, что обычная оболочка Борна работает одинаково хорошо.

Типичная ошибка: если! test $ x -eq $ y работает должным образом в bash, который имеет более умный встроенный оператор «if», но «правильный» if test! $ x -eq $ y должен работать во всех средах.