Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Alex Wells,

новые патч версии наоборот более стабильны. Возможно выше назвал их "минорными" - если так, то имел в виду именно патч. В них только багфиксы, они априори не могут быть менее стабильными)

Не должны быть, но не факт. Но речь была о другом, если ежемесячно правятся баги - это явно не стабильная версия. Значит есть предыдущая мажорная или минорная версия, которая работает уже достаточно давно, и если там случается найти баг, то это очень редко, соответственно никто там каждый месяц уже не правит баги. Про это я и писал, что лучше подождать с новинками, но зато работать с более стабильным ПО, тем более когда речь идет о такой капризной штуке как СУБД.

Остальные цитаты, это не мои.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Alex Wells, написал про bash подробнее чуть выше. А вот про обновление СУБД раз в месяц, соглашусь с Saboteur, если вы заботитесь о стабильности работы - это не лучший подход. Использовать нестабильные версии, которые правятся каждый месяц - это риск словить проблемы. Любая новая версия СУБД должна проходить проверки DBA и делать это каждый месяц нереально, лучше не использовать новый функционал, чем так рисковать. Разве что стабильность не является для вас важным фактором и вы готовы так рисковать.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur, читаю что вы пишите, но у вас только эмоции и утверждения без обоснования: "синтаксис прекрасен", "нормальные люди", "это оверинженеринг" и все тут. Все что я пишу про bash нисколько его не принижает, это прекрасный инструмент, его внутренней реализации вполне хватает для его целей. До тех пор пока вы его не запихиваете в один ряд с языками программирования.

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

Ладно, называйте их все языками программирования. Но все эти сравнения абсолютно не уместны. Bash и прочие шеллы - это совсем иное, чем python и языки программирования, совсем разное назначение. Про "библиотеки" слышать забавно, сами же писали про высокие затраты на fork.
Другое дело никто не назовет это библиотеками, даже при микросервисной архитектуре, сервисы разносятся совсем не потому что ЯП не позволяет писать эти сервисы.
И вообще, говорить про то, что любая консольная команда становится "библиотекой" можно только, если вы не писали на bash ничего более-менее сложного. Если бы писали, то знали, что вывод многих команд очень слабо подходит для машинной обработки, и дело не в хитрых манипуляциях в sed, а в том что нельзя гарантировать, что в выводе что-то неожиданно не изменится. Любой разработчик, знает что такое API, и знает что выше описанный подход - хрень полная.

либо вы не понимаете, как работает баш, либо не знаете что в баш даже отдельно существуют типы данных integer string и array. И внутренняя реализация этого вполне достаточна для баш скриптов.

Не игнорируйте, расскажите, как вы будете складывать числа с плавающей точкой в этом универсальном ЯП. Не забудьте рассказать про затраты на fork. Ну и параллельно, расскажите что же там за типы integer и array при таких вычислениях. Я прекрасно понимаю, что это вызов внешних команд, но не я заявлял, что они библиотеки.
И это просто элементарные вычисления, мы даже близко не рассматривали математический аппарат настоящих ЯП, и тем более такого языка как python.

Примитивный анализатор ;))))) это смешно.

Примитивный - это не попытка обидеть вашу любимую игрушку, это констатация факта. Если в python вы положите команду в переменную, она не начнет выполнятся при выводе на экран. Чтобы добится такого же поведения в python, нужно взять динамический код, заменить переменные через тупо подстановку строк, а затем выполнить через внутреннюю команду исполнения кода. И, привет от инъекций кода. Кто писал внутренние языки прекрасно это знают, остальные знают по sql-инъекциям.
Т.е. дело не просто в экранировании, проблема глубже в отсутствии разделения данных и кода, для командного процессора - это нормально, для ЯП - это ад.

Проблема большинства ООП программистов - оверинженеринг. Огромный оверинженеринг.
Контейнеры - то есть чтобы запустить скрипт установки mysql или скрипт для обновления версии httpd вы будете устанавливать докер и запускать контейнер?

Это не проблема, мы сознательно жертвуем производительностью ради более удобной и легко контролируемой структуры. Либо не жертвуем в тех местах, где иные приоритеты (и вообще возьмем какой-нибудь Go или Си). Но писать про это предлагая взамен полное копирование всех страниц памяти интерпретатора (fork) даже при элементарных операциях - это показывать полное непонимание на чем можно экономить, а на чем нельзя.
Тоже самое про контейнеры, вы не понимаете, что каждый инструмент имеет область применимости. Никто не придет к вам домой инспектировать ваш комп на наличие вагранта. Но при разработке стек бывает достаточно большой, с сложными зависимостями, сторого определенными версиями продуктов, и чтобы развернуть это все с нуля потребуется не час и не два.

Не понимаю какое вообще отношение ООП имеет к if и for, вы точно считаете, что знаете что такое ООП? ;)

Ну не я же писал, что циклов и ветвлений достаточно, а структуризация ненужный "оверинженерниг".

Кроме того, я не сисадмин и в свое время работал с Си со всей заморочкой с указателями и работой с памятью.

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

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur, именно так, примитивный, как уже написал, просто подстановка строки в строку. Вы либо не понимаете, как он работает, либо просто ничего другого не знаете. Но по делу, смотрю вам сказать нечего, "нормальные люди" это, конечно, "весомый" аргумент. Понимаю, что для сисадмина все разработчики занимаются фигнёй, ведь все можно просто и легко сделать в bash. Но, действительно, спорить бесполезно с человеком, кто не писал ничего сложнее скриптов автоматизации. Для которого использование переменных - это заменить подстроку в строке, типы данных не нужны, раз есть поток строк, а ООП бесполезная трата ресурсов, ведь все можно сделать через if и for. Ведь создать объект тяжёлая операция, а полное копирование памяти интерпретатора при fork бесплатное похоже? А fork при попытке сложить 2 числа вообще сказка! Поэтому у нормальных людей, раз уж вы так написали, bash для автоматизации запуска приложений и скриптов, а языки программирования для разработки этих приложений и скриптов. А остальные входят в клуб любителей путать молоток и микроскоп.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur, абсолютно серьезно, совместимость - это когда результат выполнения предсказуем и одинаков, а не "может сработает, а может нет".
Ситаксис bash ужасен, если сравнить с языком програмирования. И дело не в разделителях-пробелах и вспомогательных конструкциях (типа скобок), которые на самом деле являются командами, хотя это мученье для любого программиста. Дело в примитивном синтаксическом анализаторе, который в принципе не передает переменные, а осуществляет тупо замены в строках, разумеется о разделении кода и данных речи вообще не идет. Но, как я уже писал, для командного процессора это нормально. И да, не для программиста, он вероятно проще и понятнее.
Bash - отличный командный процессор, прекрасно справляющийся со своим назначением - автоматизацией запуска команд ОС. Поэтому фраза "отличный универсальный скриптовый язык программирования" забавна, а сравнение на этом фоне с питоном вообще уморительно. Пофиг на фразу "язык программирования", но ничего универсального в нем нет, это узко специализированный скриптовой интерпретатор, занимающийся запуском других программ, и мало что умеющий кроме этого.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur, "скрипт написанный на питон 10 лет назад - несовместим" - это проблема любой сложной системы, или делаешь ворох костылей и спотыкаясь дальше тянешь совместимость, или делаешь новое, несовместимое. У bash вроде бы нет проблем с обратной совместимостью, потому что он гораздо более простой чем язык программирования, и потому что ничего принципиально не меняет.
bash не является стандартным shell, да мало кто видел ash, zsh и прочие, но sh имеет достаточно широкое распространение. При этом bash и sh несовместимы.
Назвать bash языком программирования у меня бы язык не повернулся, с точки зрения любого языка программирования синтаксис bash ужасен. Но нужно понимать что это командный процессор, а не язык, что многое объясняет.
Удобство bash в автоматизации - это не заслуга какой-то крутой внутренней структуры самого bash, а заслуга философии UNIX и реализация ОС GNU, и bash лишь звено замечательного набора утилит: sed, grep, awk, head, tail и т.п. и круто смотрится только в сочетании с ними.
Не вижу проблемы в fork, если мы зафигачим на место bash какой-нибудь python, поправьте если не прав, почти все что будет скопировано при форке понадобится в дальнейшем. К тому же, как правило разные процессы интерпретаторов не тянут все в свой процесс, они будут тяжелее безусловно, но вряд ли критично тяжелее. Кстати, Ubuntu насколько знаю сейчас активно использует python как скрипт автоматизации внутри дистрибутива.

Как правильно решить конфликты в dev ветке для двух веток в разработке?

Antonio Solo, правильно. Только эту функцию уже выполняет dev, поэтому важно как автор с ней работает, просто ввод новой ветки ничего не даст, если он с ней будет работать как привык.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur, просмотр истории команд выполняется внешней утилитой history, хотя и вещь очень простая, настраиваемое приглашение командной строки - задача вполне тривиальня, если под навигацией подразумевается автокомплит, то это тоже не из ряда вон выходящая задача. Про Ctrl+C не очень понял проблемы, тривиальный вопрос обработки сигнала ОС, поставьте свой обработчик, который не будет реагировать на сигнал и ваш скрипт точно также не будет прерываться по Ctrl+C. Т.е. это все вообще не проблема.
"Просто взять питон" действительно плохое решение, но я думаю, что мало кто дорабатывает языки программирования для использования как shell, просто потому, что bash с примитивным синтаксисом подходит как нельзя лучше именно из-за своей простоты и легковесности.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Марат Нагаев, интерпретатор языка - это нехилая хрень, которая включает в себе огромное кол-во функционала: поддержка различных типов данных, сложный математический функционал, парсинг какого-нибудь json и еще куча всего. Командный процессор, он же shell, и в частности bash - это легкая программа, ее задача запустить другую программу, передать что-то на вход, забрать что получилось на выходе и передать дальше - все, в ней практически нет встроенных операторов. Т.е. мы сознательно теряем в быстродействии из-за необходимости загрузки различных внешних программ и передачи данных между ними, но выигрываем в легковесности основной программы, т.к. в большинстве случаев функционал языка общего назначения не нужен на 98%.

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

Не так, есть просто программа bash. Ее может запустить ОС автоматически или по запросу пользователя. Она может работать интерактивно, ожидая и реагируя на ввод пользователя, либо выполняя набор команд переданный через файл, через аргументы или во входящий поток.
У bash есть небольшой, очень ограниченный набор встроенных операторов (который может отличаться от других shell, таких как sh, zsh, ash и прочих), но назвать это языком сложно.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

FanatPHP, ну вот и для меня выглядит странно деление на "оболочка и язык", и "интеграции с command shell". Есть программулина bash, и без разницы кто или что ее запускает, в интерактивном режиме, или список команд передается параметром или через файл.

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

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

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

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

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

Что за разные баши, он же один? О каких "обертках" идет речь?

Как правильно решить конфликты в dev ветке для двух веток в разработке?

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

Какие способы общения есть между серверным и клиентским приложением?

res2001, ок, я так и написал. Просто под стеком TCP/IP подразумевается стек протоколов, а никак не реализация. И нет никакой стандартной реализации TCP/IP, как минимум у каждого ядра ОС она своя. DPDK, к примеру, дорабатывал реализацию FreeBSD.

Какие способы общения есть между серверным и клиентским приложением?

res2001, почему DPDK используют не стандартный стек TCP/IP? Если они используют не стандартный стек, то как к ним подключаются обычные машины, не DPDK? Ведь, DPDK - это серверное решение, для обеспечения высокой производительности сетевой передачи, за счет прямой работы с сетевой картой, а не через ОС.
Или я не прав?

В каких случаях MariaDB может быть предпочтительнее PostgreSQL?

beduin01, чаще всего нормальная настройка - это оставить дефолтные настройки и трогать только то, что действительно нужно, а то что действительно нужно выявляется в процессе эксплуатации. Большинство проблем как правило возникает, когда кто-то начинает "настраивать" БД заранее и полагаясь на свои "знания".
Любая СУБД имеет свои плюсы и минусы. MySQL очень быстрый на вставках, MariaDB скорее всего тоже. Вообще MySQL/MariaDB более простая СУБД и от того быстрая. В сборке от Percona MySQL будет быстрее PostgreSQL на простых запросах уж точно. У той же Percona есть и хорошие утилиты мониторинга. А вот план в MySQL был и остается хренью, почти бесполезной для чего-то серьезного. Но если вы собираетесь использовать СУБД как приложение с бизнес-логикой (хранимки, жонглирование json), то MySQL/MariaDB явно неудачный выбор. Что говорить, они даже с prepared statements работают тормознуто.

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

Наверное, ky0 имел ввиду другое. Но, действительно, на этапе, когда важна скорость БД, когда даже контроль консистентности данных переносится в приложение, MySQL может оказаться лучшим решением.

И, соглашусь, на практике главенствует принцип выбора:

Если те, кто разрабатывает приложение и обслуживает базу лучше знает эту софтину, чем постгрес.

Как сделать sleep на N секунд либо до прихода HTTP запроса (асинхронный cron с http сервером)?

Целый веб-сокет сервер, только чтобы "пнуть" демона? Который по-сути будет работать только для 1 клиента, вряд ли соединение будут держать постоянно, для таких редких запросов это напрасная трата ресурсов, а значит моментальности не будет тоже (да и не нужна она здесь). Не проще ли тогда через http?

Какова best practice для преобразования входящего JSON при создании/обновлении модели через API, где это принято делать?

Роми, я даже не знаю, что там смотреть. json с описанием модели, тупо свойства и их типы, и где модель будет лежать. И на основе его создать модели, с геттерами, сеттерами или заполнением на основе массива, и стандартной вашей валидацией этих типов. Можно, конечно, подсмотреть это в фреймворке, в том где есть генераторы моделей, например для работы с БД, но по-моему дольше будете разбираться в избыточном функционале, который для этой задачи не нужен.

Как сделать sleep на N секунд либо до прихода HTTP запроса (асинхронный cron с http сервером)?

Ярослав,

Поэтому хочется иметь дублирующий механизм который просто по тайм-ауту будет выполнять проверки. (нет новостей 5 минут? Окей, проверим сами). Но он не запускается если оповещения приходят достаточно часто.

Чтобы не проверять параллельный запуск: 1 демон, который каждые 5 минут делает работу. Сделав работу он слушает tcp-порт или даже unix-сокет, и ждет команды на досрочный запуск (http здесь избыточен).
Если удобнее по http, а впиливать в демон даже урезанный http-сервер не хочется (или он уже есть), то отдельно стоящий веб-сервер, запускаемые из него скрипты, которые посылают стандартный unix сигнал демону. Нужно будет передавать pid для этого, но вероятно это проще сделать через systemd.

Какова best practice для преобразования входящего JSON при создании/обновлении модели через API, где это принято делать?

Роми, нет, сделайте модели Request, которые будут знать что там приходит в запросе и будут эти данные валидировать. И именно в этих моделях будет простыня. Т.е. то что написал jazzus. Если таких моделей много, сделайте генератор кода, который будет генерить нужные модели по описанию.