Яка перевага оболонки скрипта перед інтерпретованими мовами програмування? [зачинено]

(Я не впевнений, чи тут це відповідне питання)

Сценарії оболонки, як і написані в них 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 потрібно імпортувати три бібліотеки, в той час як все, що потрібно для цього завдання, доступне в базі
• Сценарій 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досить різні. Однак вони не мають статичного типу , а значить, для них потрібно мати різні літерали для того, щоб їх не було. Приклад:

   • Ruby: 123(кількість), Bash:123
   • Ruby: '123'(рядок), Bash:123
   • Ruby: /123/(regexp), Bash:123
   • Ruby: File.open('123')(файл), Bash:123
   • Ruby: IO.open('123')(дескриптор файлу), Bash:123
   • Ruby: URI.parse('123')(URI), Bash:123
   • Ruby: `123`(команда), Bash:123

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

4. У Bash & Co., файли, каталоги, дескриптори файлів, процеси - це все першокласні об'єкти, в Python лише об'єкти Python є першокласними, якщо ви хочете маніпулювати файлами, каталогами і т. Д., Вам потрібно загортати їх у Спочатку об'єкт Python.

5. Програмування оболонки - це в основному програмування потоку даних. Ніхто цього не усвідомлює, навіть люди, які пишуть оболонки, але виявляється, що оболонки в цьому непогані, а мов загального призначення не так багато. У світі програмування загального призначення, здається, потік даних розглядається в основному як модель паралельності, а не як парадигма програмування.

У мене таке відчуття, що намагатися вирішити ці пункти за допомогою підключення функцій або DSL на загальну мову програмування не працює. Принаймні, я ще не бачив переконливої ​​реалізації цього. Є RuSH (оболонка Ruby), яка намагається реалізувати оболонку в Ruby, є пік, який є внутрішнім DSL для програмування оболонок в Ruby, є Hotwire, який оболонки Python, але IMO ніхто з тих не підходить навіть близько змагатися з Башем, Зш, Рибою та друзями.

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

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

Я думаю, що хорошим правилом є:

automatingSimpleTask ? shellScript() : programmingLanguage();

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

Якщо ви абсолютно вільні у виборі мови програмування, якою ви користуєтесь для певних завдань, ви, ймовірно, майже повністю можете уникнути вивчення баш-програми та виконувати кожне завдання програмування сценарію за допомогою Perl, Python або Ruby. Іноді це може призвести до більш детального рішення, особливо в тому випадку, коли вам просто потрібен скрипт, який викликає послідовність інших інструментів Unix, але в більш складних випадках ви праві, ці сучасні мови скриптів дають більше можливостей для написання кращого доступного коду (вони також дають більше можливостей написати неясний код, але це ваш вибір).

З іншого боку, часто ми не вільні у виборі мови, яка нам найбільше подобається, тому що нам доводиться працювати зі спадковим кодом або кодом, написаним тим, хто знав bash, але не знав однієї з названих сценаріїв.

Сценарії оболонок - це інтерпретована мова програмування. Ось кілька причин, чому я вирішив писати сценарії в bash замість perl, python чи іншої мови сценаріїв:

Працює всюди : Більш складні перекладачі можуть бути не завжди доступними, наприклад, під час запуску системи або вбудованих систем. Bash доступний навіть у зайнятій скриньці.

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

Простіше писати програми, які викликають інші програми. Якщо ви намагаєтеся це об'єднати кілька існуючих програм цікавими способами, це можна зробити простіше в сценарії оболонки, ніж з мовою вищого рівня.

Якщо програма становить 30 рядків або менше, я зазвичай пишу її за допомогою сценаріїв оболонок. Якщо є якась складна маніпуляція чи складний аналіз чи аналіз, я зроблю це за допомогою python або perl.

Слід поглянути на coffeescript. Їх слова:

Під усіма цими незграбними фігурними дужками та крапками з точки зору JavaScript завжди була чудова модель об'єкта. CoffeeScript - це спроба розкрити хороші частини JavaScript простим способом.

Золотим правилом CoffeeScript є: "Це просто JavaScript".

Ну ... ось приходить відповідь супер-початківця.

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

Сценарії оболонки, як і написані в баші, можуть зробити багато речей. Вони можуть викликати програми Unix, передавати їх вихід, перенаправляти введення / виведення з / в файли, контролювати потік, перевіряти, чи існує файл тощо.

і чи не це просто фантастично! ? петлі та змінні? Оце Так!

пітон і рубін, також можуть робити ці речі. І вони (я думаю) більш читабельні та ремонтопридатні.

Скажіть, будь ласка, де ви це бачите? Я написав bashscript в gedit навіть в geany, і я можу відформатувати, (вкладки?), І я читав свій код зі швидкістю світла, використовуючи bashscript для порівняння на інших мовах.

Чи є в цих мовах інші інструменти для наведення порядку? Я знаю, що об'єктно-орієнтований економить багато коду, але ... люди кажуть, що bashscript також є ОО! WOW 2! Тут моя думка. Йду до:

перевага оболонки сценарію

всередині цього питання: Як зробити те, що може зробити цей обстріл в перлі, фітоні чи рубіні? Це легко?

( обруч = xdotool )