Почему для скриптинга в шелле используется 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. Если таких моделей много, сделайте генератор кода, который будет генерить нужные модели по описанию.

Как отправить POST запрос через Постман?

Тип запроса POST? Впрочем чего гадать, дайте запрос Постмана и посмотрим.

Как проверить значение в массиве если он пустой?

Лентюй, кстати да,
Макс В, если вдруг под числом понимается не тип элемента, а его содержание, то нужно использовать is_numeric.

Как взять следующую запись в БД после определенной?

select id from supertable where id>5 order by id limit 1

Как в php немедленно выводить данные?

Кирилл Несмеянов, не надо просто ссылку, напишите ваши аргументы, свои я написал выше.
SSE - это тот же polling, только возведенный в стандарт и реализованный внутри браузера. Принципы работы http от этого не поменялись: клиент запрашивает сервер, а сервер отвечает. При short это постоянное тюканье сервера "что нового?", при long "зависание" в ожидании ответа. Это способы обойти ограничение на отправку сообщение от сервера клиенту, а не поддержка протоколом. Неужели не видите разницы?
Так к чему эти ссылки? Я ж не отрицаю существование polling, ни то что его используют, ни то, что без него бывает не обойтись. Возможно даже, при определенных условиях, sse будет предпочтительней ws, можно поспорить. Но http работает однозначано: запрос клиента - ответ сервера, и никак иначе, т.е. "не предназначен для отправки сообщений сервером".