- 1
Давайте устроим холиворчик - скриптинг на винде против скриптинга на линупсе, или баш против помершелла-
Куча / Говнокод #18791
+2
Запостил:
3_14dar,
30 Сентября 2015
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
/thread
x/thread
Читабельные скрипты? Следующее что вы еще потребуете это интуитивные скрипты.
Большинство скриптов живут в контексте, что уже значит что читабельными для подавляющего большинства посторонних они никогда не будут.
И как концепция, скрипт это средство автоматизации. (Тыкните в англицкий словарь что такое "script".) Читабельность и прочее напрямую зависят от того что автоматизируется. И автоматизируется то что человеку делать в ручную сложно или неподъёмно. Другими словами, нечитабельность там уже в генах.
ЗЫ Я на самом деле видел пару читабельных тестовых фреймворков/тестов на Tcl. Но там читабельность была skin-deep: как только отходишь от официальных макросов, вся красота и заканчивалась. IMHO, Тцл самый читабельный скриптовый язык. Там по крайней мере можно пытатся читабельно все делать и без извратов.
Да, такое возможно. Я как-то раз по нужне лазил в debhelper, написанный на Perl. Я не изучал Perl, но код мне был вполне понятен.
А в bash извраты на каждом шагу. Как можно писать понятные сценарии без НОРМАЛЬНЫХ массивов и хэш-табличек? Да и синтаксис настолько убогий, что через раз доку нужно читать.
Сейчас внезапно многие админы, гордо именующие себя DevOps, переезжают на Go. Угадайте, почему.
> Как можно писать понятные сценарии без НОРМАЛЬНЫХ массивов и хэш-табличек?
ну это как бы и есть проблема. в смысле: большинство знает только один скриптовый язык, и поэтому на нем извращаются до последнего.
у меня есть жележное правило: как только bash скрипту нужны массивы и прочее, надо переезжать на какой перл или питон.
баш сам по себе почти идиальный язык - для запуска и контроля внешних програм, для перенаправления ввода/вывода и построения пайплайнов из внешних програм.
я пытался для перлов/питонов/тцл в прошлом тулзы такого плана делать (пайплайны из внешних програм и/или внутренних функций) но все равно то что в баше делается в пару строчек, на перле/питоне/тцл это уже десяток/больше строк.
в добавок, народ который приходит с "нормальных" языков, сильно себя не напрягают изучением парадигм шелла. 90% использования массивов/прочего в баше можно сделать и пайплайном. но блин парадигма в нормальных языках это массив с циклом - и его же пытаются лепить в шелле.
http://govnokod.ru/18771#comment299608
цитирую главный перл:
> > S-выражения. Они вполне читабельные
спасибо, посмеялся. :)
ЗЫ нужно много лет себе упорно мозги набекрень ставить, что бы s-expr'ы за читабельные считать. я был бы только рад если бы они были читабельными - регулярный синтакс ёпта - но они ни разу ни читабельные. почему и сидят в своей глубокой нише, откуда только изредка на поверхность всплывают (самые последние новости: GNU make 4.0 with Guile integration).
> спасибо, посмеялся. :)
Какие альтернативы для передачи структурированной информации по пайпам?
Бинарная сериализация? не вариант
XML? боже упаси
JSON? вариант, но не самый лучший - слишком уж много символов, мешающих читабельности.
> s-expr'ы за читабельные считать
Структура s-выражений описывается несколькими предложениями и легко понимается.
Сравни:Где больше синтаксического шума? Где проще ошибиться при наборе?
Вопрос уже сам по себе неправильный.
Вся моща шелла и пайпов состоит в том что информация неструктурированая. It's not a bug - it's a feature.
> Сравни:
> 15297 pts/41 bash
Если ты хочешь "структурировано" - то тогда бери какой питон, подключай либу для procfs/этц, и получай живые системные данные как их тебе предоставляет система, и без прослоек и извратов вокруг `ps`.
Вы пытаетесь постоянно "улучшить" шелл, даже не задумаваясь, что то что вы хотите в итоге, уже существует.
> Структура s-выражений описывается несколькими предложениями и легко понимается.
Ассемблер тоже "описывается несколькими предложениями и легко понимается".
Если ты конечно уже прочитал талмуд по Асму и талмуд по пропу. Или в твоем случае - талмуд по Common Lisp'у + талмуд по его несовместимым вариантам + талмуд по Scheme. Но как только, так сразу - "описывается несколькими предложениями и легко понимается".
Ты говоришь о семантике языков программирования, записанных S-выражениями. Она действительно не тривиальна. Сами S-выражения очень просты.
Я слишком поздно уловил что ты говоришь о сериализации данных, а не скриптовых языках.
Да. У S-expr простой синтакс.
Но как по мне, формат для представление структурированых данных это вторичный вопрос. (И можно авто-детект прикрутить: первый символ '<' - ХМЛ, '(' - S-expr, '{' - JSON.)
Главный вопрос это хочешь ли ты вообще структурированые данные по пайпам гонять. По моему личному опыту это просто не имеет смысла: ты только добавляешь overhead сериализации/десериализации данных, а выгоды (по сравнение со перл/питон скриптом который через либы к данным напрямую доступается) мало.
Иногда действительно не помешало бы. Примеры:
1. Потоковая обработка логов, состоящих из записей (дата, процесс, сообщение)
2. Выхлопы всяческих ps / mount
3. Выхлопы git / svn status
Структурированный выхлоп особенно полезен с точки зрения интеграции: когда пишешь плагин для какого-нибудь Emacs/Sublime Text, меньше всего хочется завязываться на изменчивый мир плейнтекста.
В общем, в PowerShell пошли по пути протаскивания объектов по пайпам, для написания именно скриптов от этого действительно профит есть.
> 1. Потоковая обработка логов, состоящих из записей (дата, процесс, сообщение)
это уже по многим причинам не стоит писать на шелле.
> 2. Выхлопы всяческих ps / mount
для ps есть правильные нативные либы.
> 3. Выхлопы git / svn status
для SVN точно есть либы.
для git'а что я делал полагается на вывод и некоторые скрипты (синхронизация между git и svn/clearcase) работают на ура больше 5ти лет.
> Структурированный выхлоп особенно полезен с точки зрения интеграции
Зависит от проекта, конечно, но много тулзов уже давно поддерживают либо XML выхлоп, либо предсказуемое форматирование (вплоть до CSV-совместимого вывода). Либо принимают патчи для добавления оного.
Open Source это не некрософт: тут нету 1000 разрабов которым можно дать приказ ко всем либам/этц еще один интерфейс прикрутить (как это МС делал с OLE/ActiveX/COM/DCOM/COM+ и сейчас PowerShell).
Но с другой стороны, если ты уже пользуешься Питоном и/или Перлом, то на отсутствие либов грех жаловатся. Там за десятилетия были написаны адаптеры и интерфейсы для всего чего только можно. (Перл на виндах вообще исключение - благодаря Win32 либам (в оссобенности Win32::OLE) которые уже 10+ позволяют винды иметь во все интерфейсы.)
Я знаю, что решения всех этих проблем есть, и я знаю, что они из себя представляют.
Я просто гипотетически пытаюсь представить себе мир, в котором решения были бы более простыми или же вообще не потребовались.
В этом мире программисты будут безработными :)
> В этом мире программисты будут безработными :)
Я имел в виду решения мелких проблем, ради которых приходится писать говнорегулярки. Программисты никуда не денутся, можно было бы делать больше полезного.
> это уже по многим причинам не стоит писать на шелле.
Ок, я больше не буду делать grep something *.log
Так почему не стоит? Что если я хочу искать только по сообщениям? Отрезать лишнее регулярками?
т.е. ты хочешь перехерачить шелл только потому что у тебя временные проблемы с грепом?
> Так почему не стоит?
потому что перехерачивание шелла (и адаптеры для всех утилит) стоит намного больше времени, чем те 5-10 минут что ты потеешь над регуляркой для шелла.
и опять же, я лично скатывался с грепа на перлы/питоны/руби неоднократно, когда мне было лень трехэтажные регулярки писать. на перле это часто однострочник, но иногда и больше. редко больше 10 строк, и пишется как правило за то же самое время что и регулярка для грепа.
ЗЫ смешно, но как ты это сказал, я вспомнил что на текущем проекте уже есть нечто подобное: пачка awk скриптов конвертит выхлоп кучи тулзов (включая стандартные) в JSON. этот JSON в большинстве случае отсылается на веб интерфейс, где яба скрипт данные уже и обрабатывает и т.д. но никто не мешает и в коммандной строке этот JSON мучать.
> ты потеешь над регуляркой для шелла.
Т.е. всё таки кранчить логи из консоли - Ок?
Я просто думал, что ты предлагаешь вообще логи не грепать.
> перехерачивание шелла
Да не собираюсь я (пока) ничего перехерачивать. Я просто думаю, как можно было бы сделать удобнее.
Конкретно для грепа я уже написал свой велик на Go, который параллельно ищет в логах не по /длинным/именам/файлов.лог.гз, а по метке syslog с фильтрами по датам.
Предлагаю ~thread()
мля, лог манагемент тулзов как грязи. включая пайпинг оных логов в SQL базу, где ты можешь их структурно/этц обрабатывать как хочешь. потому что на уровне сислог дата все еще юникс таймстемп - это только в текстовый лог она как строка попадает.... ваша проблема не греп и не шелл и не неструктурированые текстуальные данные...
> ~thread()
очевидно.
> на уровне сислог дата все еще юникс таймстемп
Я всё это прекрасно знаю, и о кибанах, и о логстэшах, и своих велосипедов у нас штук пять.
Необходимость в шустром грепе в локальных логах без переключения контекста никуда не делась.
Все не нужно что сломалось все не нужно чего нет? Признайте уже что подход повершелла лучше.
Потому что кругозор 3_14darа ограничен, и он не слышал ни о чём более.
Чего бы не умел повершел в винде питончик умеет больше и лучше.
Выше
>но все равно то что в баше делается в пару строчек, на перле/питоне/тцл это уже десяток/больше строк.
копулирует под копотом
Всё что не сишка -- то скриптушня.
но ты хочешь быть скриптером
он хочет быть скриптером
мы все хотим быть скриптером
Мы не братья, пидар, не прикидывайся, я имел в виду твою мать-алкоголичку. Просто может порваться манямирок оттого что ты услышишь, что некоторые вещи на самом деле не такие как талдычат тебе по телеку. Парочка уже порвалась.
Ищи.