one-liner vs script

Обратите внимание, что это личное мнение; воспринимайте это с недоверием.

1. Если команда умещается, скажем, в 80 символов, используйте один вкладыш -. С длинными командными строками трудно работать. Существует также проблема повторения, см. #2

2. Если вам нужно запустить команду (s )более одного раза, используйте сценарий. В противном случае используйте один вкладыш -при условии соблюдения условия #1.

3. Это очень субъективно, но да, я рассматриваю shell, Perl или awk в качестве -инструментов для одного -лайнера.
4. См. #1, #2, #3.

Написать сценарий , когда:

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

Запишите один -вкладыш , когда:

• требуется лишь небольшой объем кода
• вы хотите получить доступ к переменным, определенным в текущей оболочке
• вам нужно быстрое и грязное решение

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

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

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

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

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

По сути, это вопрос, -основанный на личном мнении, поскольку он включает в себя определение допустимой степени сложности и поиск компромисса между удобочитаемостью и компактностью; все это в значительной степени вопросы личного суждения. Даже выбор языка может зависеть от личных обстоятельств :, если конкретный язык теоретически был бы оптимален для конкретной задачи, но вы с ним не знакомы и уже знаете, как решить задачу на каком-то другом языке, вы можете выберите знакомый язык, чтобы выполнить работу быстро и с минимальными усилиями, хотя технически решение может быть несколько неэффективным.

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

И если вы знакомы с Perl, вы, возможно, уже слышали о TMTOWTDI.:Существует более чем один способ сделать это.

Я полагаю, что в большинстве случаев запрос на «один -лайнер» на самом деле является запросом на «звуковой отрывок», то есть:

In the context of journalism, a sound bite is characterized by a short phrase or sentence that captures the essence of what the speaker was trying to say, and is used to summarize information...

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

Иногда невозможно сократить речь до «звукового отрывка», а также невозможно сократить сценарий до короткого «одного -лайнера». В таких случаях единственным возможным ответом является сценарий.

И, вообще, "звуковой отрывок" никогда не бывает хорошей заменой всей речи. Таким образом, «один вкладыш» обычно хорош только для того, чтобы передать идею или дать практический пример этой идеи. Затем, после того как идея понята, ее следует расширить (применить )в сценарии.

Итак, напишите «один -вкладыш», чтобы передать идею или концепцию.

Пишите общий код в виде полноценных скриптов, а не одной -строчки.

Должен сказать, что я несколько напуган последствиями первой части вопроса. Языки сценариев Unix — это полноценные -языки программирования, а языки программирования — это языки , что означает, что они примерно так же бесконечно податливы и гибки, как человеческие языки. И одна из отличительных черт «бесконечной податливости и гибкости» состоит в том, что почти никогда не существует «одного правильного способа» выражения чего-либо --, существует множество способов,и это хорошо! Так что да, конечно это вопрос личных предпочтений, и в этом нет ничего плохого. Всякий, кто говорит, что есть только один способ сделать что-либо, всякий, кто выражает презрение к (или невыполнению )чего-либо тем или иным способом, вероятно, является педантом или предписателем.

Когда-то мой собственный ~/binбыл полон "полезных" маленьких скриптов, которые я написал. Но я понял, что большинство из них использовалось в тот же день, когда я их написал, и больше никогда. Таким образом, чем больше времени проходит, тем меньше становится мой каталог bin.

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

Причины, по которым я больше не пишу сценарии так часто (и, полагаю, отдаю предпочтение «одному -лайнеру»):

• binБеспорядок в каталогах имеет свою цену. Я больше не кладу туда вещи, если они действительно не принадлежат этому месту.
• Языки сценариев, которые я использую, — это языки, которые я использую ; Я действительно facile с ними сейчас. Перепечатывать один -лайнер всякий раз, когда мне это нужно, не похоже на работу; Я не чувствую себя обязанным хранить, сохранять и использовать сценарий только для того, чтобы облегчить бремя ввода (re ). (Среди прочего, в какой-то момент бремя перепечатывания становится меньше, чем бремя памяти, необходимое для запоминания того, что такое сценарий.)
• Еще одна причина, по которой перепечатывание не кажется обременительным, — это :история команд. Есть много -лайнеров, которые я не закрепил как сценарии, хотя я использую их каждый день --, но мне не нужно их перепечатывать; Я просто вспоминаю их из истории. В этом смысле они своего рода -подлинники или псевдонимы бедняков.

Похоже, я придерживаюсь мнения меньшинства по этому поводу.

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

В команде я предпочитаю писать программное обеспечение с кодом, -процесс проверки которого осуществляется с помощью инструмента (github/gitlab/gerrit ). Это дает контроль версий в качестве бонуса. Если у вас несколько систем, добавьте инструменты непрерывного развертывания. И несколько наборов тестов, если важны целевые системы. Я не религиозен в этом, но взвешиваю выгоды и затраты.

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

Я предпочитаю один -вкладыш на самом деле для всего, что не заслуживает этого "тяжелого" процесса. Их можно быстро повторно использовать несколькими нажатиями клавиш, если вы знаете, как эффективно использовать историю оболочки; легко вставляется между несвязанными системами (, например. разные клиенты ).

Принципиальная разница между (не рассмотренным! )один -лайнер и рассмотренное программное обеспечение ("сценарии" ):ответственность полностью лежит на вас, когда вы выполняете один -лайнер. Вы никогда не сможете сказать себе: «Я только что нашел где-то этот -лайнер, я запускал его, не понимая, что дальше — не моя вина» -вы знали, что запускаете непроверенный и непроверенный фрагмент -из -программного обеспечения, так что это ваша вина. Убедитесь, что он достаточно мал, чтобы вы могли предвидеть результаты -, будь они прокляты, если вы этого не сделаете.

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

Вы спрашиваете о «страхе и презрении к сценариям». Это происходит из-за ситуации 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". Но ответа ситарама больше нет. Надеюсь, мой ответ все еще имеет смысл.

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

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

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

Иногда для выполнения каких-либо действий требуется целая группа команд, например, для настройки некоторого оборудования; в конце я копирую их все из истории, минимально подчищаю и добавляю в shell-скрипт RUNMEпросто как заметки о том, что я сделал, но также так, чтобы они были почти готовы к повторному использованию кем-то другим. (Вот почему мне так сложно найти инструменты, которые предоставляют только графический интерфейс для их настройки. )Я нахожу это невероятным приростом эффективности, так как часто то, что вы ожидаете сделать только один раз, приходится делать еще 5 раз...