сценарій з одним лайнером

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

• Коли і навіщо мені писати автономний сценарій, а не «однолінійний»? Або навпаки?

• Які випадки використання та плюси та мінуси обох?

• Чи деякі мови (наприклад, awk або perl) краще підходять для однокласників, ніж інші (наприклад, python)? Якщо так, то чому?

• Це лише питання особистої переваги чи є вагомі (тобто об’єктивні) причини писати те чи інше в конкретних обставинах? Які ці причини?

Визначення

• one-liner: будь-яка послідовність команд, набраних або вставлених безпосередньо в командний рядок оболонки . Часто з участю трубопроводів і / або використання мов , таких як sed, awk, perl, і / або інструменти , такі як grepабо cutабо sort.

  Саме визначальним характеристикою є пряме виконання в командному рядку - довжина та форматування не мають значення. "Одне вкладиш" може бути усім на одному рядку, або він може мати декілька рядків (наприклад, sh для циклу, або вбудований код awk або sed, з каналами рядків та відступом для поліпшення читабельності).

• script: будь-яка послідовність команд на будь-якій інтерпретованій мові, які зберігаються у файлі та виконуються. Сценарій може бути написаний повністю однією мовою, або він може бути обгорткою сценарію оболонки навколо декількох "однокласників", використовуючи інші мови.

У мене є своя відповідь (яку я опублікую пізніше), але я хочу, щоб це стало канонічним питанням питань, а не лише моєю особистою думкою.

Ще одна відповідь, заснована на практичному досвіді.

Я б скористався однолінійним кодом, якби це був "викинутий" код, який би я міг написати прямо під запитом. Наприклад, я можу використовувати це:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

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

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

Узагальнення, можна сказати

• Однолінійний

  • Простий код (тобто лише "кілька" тверджень), написаний з певною разовою метою
  • Код, який можна швидко і легко записати, коли це потрібно
  • Одноразовий код

• Сценарій

  • Код, який (ймовірно) буде використовуватися більше одного чи двох разів
  • Складний код, що вимагає більше, ніж "кілька" висловлювань
  • Код, який потребуватимуть інші
  • Код, який повинні розуміти інші
  • Код, який слід запускати без нагляду (наприклад, від cron)

Я бачу досить багато запитань тут на unix.SE, щоб задати однолінійку для виконання певного завдання. Використовуючи мої приклади вище, я вважаю, що другий набагато зрозуміліший, ніж перший, і тому читачі можуть дізнатися більше з нього. Одне рішення може бути легко виведене з іншого, тому в інтересах читабельності (для майбутніх читачів) нам, мабуть, слід уникати надання коду, видавленого в один рядок, для чогось іншого, крім самих тривіальних рішень.

Напишіть сценарій, коли:

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

Напишіть однолінійку, коли:

• потрібна лише невелика кількість коду
• ви хочете отримати доступ до змінних, визначених у поточній оболонці
• вам потрібно швидке і брудне рішення

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

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

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

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

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

Це по суті питання, що ґрунтується на думці, оскільки воно передбачає визначення того, яка кількість складності є прийнятною та компроміси між читабельністю та компактністю; все це дуже важливо для особистого судження. Навіть вибір мови може залежати від особистих питань: якщо певна мова теоретично була б оптимальною для певної проблеми, але ви їй незнайомі, і ви вже знаєте, як вирішити проблему якоюсь іншою мовою, ви можете вибрати знайома мова для того, щоб виконати роботу швидко та з мінімальними зусиллями, хоча технічно рішення може бути дещо неефективним.

Найкращий часто є ворогом достатньо доброго , і це дуже стосується тут.

І якщо ви знайомі з Perl, можливо, ви вже чули про TMTOWTDI: Існує більше, ніж один спосіб зробити це.

Зверніть увагу, що це особиста думка; візьміть його з зерном солі.

1. Якщо команда підходить, скажімо, до 80 символів, скористайтеся одноланковою. Довгі командні рядки важко працювати. Також існує проблема рецидиву, див. №2

2. Якщо вам потрібно запускати команди (команди) більше одного разу, використовуйте скрипт. В іншому випадку скористайтеся одноклассником за умови дотримання умови №1.

3. Це дуже суб'єктивно, але так, я вважаю, що оболонка, Perl або awk є моїми інструментами для одноразових вкладок.
4. Див. №1, №2, №3.

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

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

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

Іноді цілій групі команд потрібно щось робити, як-от налаштувати деяке обладнання; наприкінці я копіюю їх із історії, мінімально очищую їх і додаю до скрипту оболонки так RUNMEсамо, як примітки до того, що я зробив, але також так, щоб вони були майже готові знову використовуватись кимось іншим. (Ось чому я знаходжу інструменти, які забезпечують лише графічний інтерфейс, щоб налаштувати на них такий біль.) Я вважаю це неймовірним підвищенням ефективності, оскільки так часто щось, що ви розраховуєте зробити лише один раз, доводиться робити ще 5 разів. .

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

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

Це незалежно від того, яка мова використовується для програмування.

На інших робочих місцях можуть бути подібні / різні звичаї чи очікування, можливо навіть записані.

Вдома ви робите все, що хочете.

Наприклад, я пишу сценарії, як тільки роблю щось нетривіальне в оболонці, як-от перед тим, як надсилати відповідь на питання U&L, або коли мені потрібно перевірити окремі компоненти команди або набір команд, перш ніж запустити її "для справжній ».

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

• оновлення моєї системи OpenBSD та всіх встановлених пакетів (це зводиться до трьох коротких команд та кількох інших для ведення господарства, зібраних у короткому сценарії), або
• створення резервної копії моєї системи на зовнішньому сховищі (по суті, єдина команда, але знову ж таки з досить великою кількістю ведення господарства, і сценарій також дозволяє мені робити різницю між знімками тощо. Я запускаю це з роботи з крон), або
• отримання пошти (знову ж таки, по суті, одна команда, але я хочу, щоб вона поводилася по-різному, коли її викликали як роботу cron, і коли я використовую її з командного рядка, і вона не повинна намагатися за певних обставин отримати пошту, і вона пише коротке повідомлення журналу до файлу).

Я використовую функції оболонки (дуже рідко псевдоніми) для зручності в інтерактивних оболонках, наприклад, для додавання параметрів певних команд за замовчуванням ( -Fдля ls) або для створення спеціалізованих варіацій деяких команд ( pmanось manкоманда, яка розглядає лише інструкції POSIX, наприклад) .

Схоже, я дотримуюсь меншості щодо цього.

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

В межах команди я вважаю за краще писати програмне забезпечення з процесом перегляду коду, що застосовується інструментом (github / gitlab / gerrit). Це дає контроль над версіями як бонус. Якщо у вас кілька систем, додайте інструменти безперервного розгортання. І деякі тестові набори, якщо цільові системи важливі. Я не релігійний щодо них, але зважую переваги та витрати.

Якщо у вас є команда адміністраторів, найпростіший vim /root/bin/x.sh- це здебільшого катастрофа з точки зору зв'язку, пов’язаної зі змінами, читабельності коду та міжсистемного розповсюдження. Часто одна серйозна несправність коштує більше часу / грошей, ніж нібито «важкий» процес.

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

Принципова різниця між (непереглянуті!) Однокласниками та переглянутим програмним забезпеченням ("скриптами"): відповідальність повністю покладається на вас, коли ви виконайте однолінійні вкладиші. Ви ніколи не можете сказати собі : «Я тільки що знайшов це один-лайнер де - то, я побіг , не розуміючи, що за цим послідувало не моя вина» - ви знали , що ви працюєте Нерецензірованное і неперевірене програмне забезпечення біт з-, так що це ваша вина. Переконайтеся, що він досить малий, щоб ви могли передбачити результати - будьте прокляті, якщо цього не зробите.

Інколи вам потрібен такий спрощений підхід, і встановлення смуги приблизно на один рядок тексту добре працює на практиці (тобто межа між переглянутим та непереглянутим кодом). Деякі мої однолінійки виглядають жахливо довгими, але вони працюють ефективно для мене. Поки я їх оброблю і не заношу на молодших колег, все нормально. Щойно мені потрібно поділитися ними - я проходжу стандартний процес розробки програмного забезпечення.

Треба сказати, що я дещо жахнувся наслідками перших частин питання. Мови сценаріїв Unix - це повноцінні мови програмування, а мови програмування - це мови , що означає, що вони такі ж нескінченно податливі та гнучкі, як і людські мови. І однією з ознак "нескінченної ковкості та гнучкості" є те, що майже ніколи не існує "одного правильного способу" висловити щось - існують різновиди способів, і це добре! Так, так, звичайно, це питання особистої переваги, і в цьому немає нічого поганого. Кожен, хто каже, що існує лише один спосіб зробити щось,

Колись у мене ~/binбуло повно "корисних" маленьких сценаріїв, які я написав. Але я зрозумів, що більшість із них звикла того дня, коли я їх написала, і більше ніколи. Отже, чим більше часу проходить, тим меншим binстає мій каталог.

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

Причини я більше не пишу сценарії (і, мабуть, надаю перевагу "одностроям"):

• binзахаращення каталогу не має витрат. Я більше не кладу речі, якщо вони справді там не належать.
• Мови сценаріїв, якими я користуюся, - це мови, якими я користуюся ; Я до цих пір знаюсь з ними. Перебираючи одноколісний кожух, коли мені це потрібно, це не відчуває роботи; Я не відчуваю мандату зберігати та зберігати та використовувати сценарій лише для зняття (повторного) набору тексту. (Крім усього іншого, в якийсь момент тягар перезарядження стає меншим, ніж тягар пам'яті запам'ятовування, що таке сценарій.)
• Ще одна причина, що переробляти речі не здається тягарем: історія команд. Є безліч однокласників, які я не закріпив як сценарії, хоча я їх використовую щодня - але мені не потрібно їх повторно вводити; Я просто згадую їх з історії. Таким чином вони складають сценарії чи псевдоніми бідолахи.

Я вважаю, що більшість часу запит на "однолінійний" насправді є запитом на "звуковий укус", тобто:

У контексті журналістики звуковий укус характеризується короткою фразою чи реченням, що фіксує суть того, що намагався сказати оратор, і використовується для узагальнення інформації ...

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

Іноді немає можливості зменшити промову до "звукового укусу", а також неможливо зменшити сценарій до короткого "однолінійного". У таких випадках єдиною можливою відповіддю є сценарій.

І взагалі «звуковий укус» ніколи не є доброю заміною всієї промови. Отже, "один лайнер", як правило, добре лише передати ідею або надати практичний приклад такої ідеї. Потім, після розуміння ідеї, її слід розширити (застосувати) у сценарії.

Отже, напишіть «однолінійку», щоб передати ідею чи концепцію.

Запишіть свій загальний код як повний сценарій, а не однолінійний.

Ви запитуєте про "страх і зневагу до сценаріїв". Це пов’язано із ситуацією Q + A, де часто відповідає відповідь: йому потрібен цей крок і це, але я також можу поставити його в один рядок (так що ви можете скопіювати вставити його і використовувати його як довгу просту команду).

Іноді ви можете лише здогадуватися, чи краще Q допомагає швидке та брудне рішення для копіювання пасти, чи «хороший» сценарій - саме те, що Q має розуміти.

Багато плюсів і мінусів тут правдиві, але все-таки вони відсутні. Я б навіть сказав, що визначення в Q не є корисними.

Файли історії оболонок - це "один вкладиш", але вони все ж зберігаються. Функція bash operate-and-get-next (C-o)навіть дозволяє повторити їх напівавтоматично.

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

history -r fileце спосіб прочитати один чи багато командних рядків (та коментарів) з будь-якого файлу, а не лише з файлу історії за замовчуванням. Просто потрібна мінімальна організація. Не слід покладатися на великий розмір файлу історії та пошук історії, щоб отримати (деяку) версію командного рядка.

Функції слід визначати аналогічно. Для початку поставте thisfunc() {...}у своєму домашньому режимі файл "функції" та надрукуйте його. Так, це накладні витрати, але це загальне рішення.

Якщо ви зберігаєте кожен командний рядок та кожну варіацію сценарію в окремому файлі, це (теоретична, але об'єктивна) витрата блоків файлової системи.

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

@sitaram: ваш один лайнер дійсно має un-onelinerish функції: лінія shebang, нова лінія, чотири виклики утиліти - два з них sed "програми". Я думаю, що оригінальний сценарій Perl виглядав приємніше і біг швидше, і не витрачав жодних байт, розкидаючись на 60 рядків. І Perl також дозволяє вам трохи стиснути.

Для мене саме такого типу вкладишів уникати. Чи хочете ви мати це (вставлене) у вашому командному рядку? Ні, і тоді, якщо ви все-таки зберігаєте його у файлі (незалежно від сценарію чи функції), ви, можливо, вкладете два-три байти нового рядка, щоб він виглядав --- приємно.

10 хв. пізніше: я просто хотів перевірити, чи можу я сказати "дві програми sed" або це "дві заміни / виклики sed". Але відповіді ситарама вже немає. Моя відповідь все ще має сенс, я сподіваюся.