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

Question

[Марат Нагаев]

Насколько я понимаю раньше шеллы использовались в качестве примитивных высокоуровневых языков. Сейчас у нас есть Perl, Python, nodejs, php...
Какой тогда смысл в bash (кроме поддержки легаси скриптов, разумеется), если для всего в осях есть сис. вызовы, а в языках программирования - соответствующие обертки над этими сис. вызовами.

Comments

[FanatPHP]

ну напишите мне на питоне хотя бы такое

zgrep '255.255.255.255' access.log* | grep delivery | grep info | cut -d'?' -f1 | cut -d' ' -f1,3,9,10,12

И вместе посмотрим, так уж ли нужен баш

[Валентин]

Философия NIX - каждая программа должна делать только одно действие и делать это хорошо. Чтобы склеить действия разных команд нужен простой и быстрый инструмент. Bash (точнее, языки типа shell - sh, tcsh, bash, etc.) является этим инструментом. Можно считать, что bash - это клей linux системы)

И для выполнения своих функций (быстро склеить два куска рутинной работы, результат которой может быть даже нужен только один раз) он подходит лучше гвоздя с молотком в виде python/perl/php или даже "сварки" библиотек с помощью C/Go/Rust.

[Марат Нагаев]

FanatPHP, это называется pipe, если я ничего не путаю.
Ниже я уже писал, что можно добавить в general purpose языки спец. синтакис как раз для этого
Тогда реализовать будет несложно.

[FanatPHP]

Да pipe - это только один из миллиона элементов баша. заточенных под запуск программ. В общем я там ниже уже подробнее расписал

[kprohorow]

Марат Нагаев, тут уже и c++ предлагали в качестве скриптового языка. Но как говорил великий мастер Foo – "В одной строчке баш-скрипта больше духа Unix, чем в десяти тысячах строк кода Си".
Изучайте коаны unix и обретайте просветление!

Если что, это "Master Foo and the Ten Thousand Lines"

[vreitech]

каждый инструмент хорош на своём месте. bash в качестве оболочки для взаимодействия с ОС будет получше питона и прочих перлов.
попробуйте реализовать это на чём-то кроме баша и скажите, успели ли вы за полторы минуты:

for host in master-db{1..3} slave-db{1..8}; do echo -n "${host} "; ssh ${host} 'grep -P '\''^#UUID=[\da-f-]+\s\/var\/lib\/mysql'\'' /etc/fstab | grep -oP '\''(?<=UUID\=)[\da-f-]+'\'''; done

[FanatPHP]

vreitech, у автора есть "прекрасный" аргумент - "ну вот это всё надо добавить в другой язык программирования" )))

[Roman K]

FanatPHP, в этом аргументе очевидно кроется и ответ на вопрос "зачем нужен баш": "этого /*всего*/ пока нет в других языках программирования"

[FanatPHP]

Roman Kitaev, дада, звучит примерно как "пока ещё я не миллиардер, окруженный озабоченными девстенницами" :)

Answer 1

[Saboteur]

Насколько я понимаю раньше шеллы использовались в качестве примитивных высокоуровневых языков. Сейчас у нас есть Perl, Python, nodejs, php...

Ну давайте вместо рабочего стола пользователю дадим сразу Visual Studio, ведь какая разница как программу запускать - иконкой на рабочем столе, или форкать из высокоуровневого языка?

shell - это оболочка операционной системы. То, что кроме графической есть еще и command line interface - это совершенно нормально и адекватно. И шелл позволяет пользователю и администратору работать в операционной системе гораздо удобнее, чем через язык программирования.

То, что sh/bash и другие, настолько развиты что сами по себе являются неплохими языками программирования - это просто следствие того, что командый интерфейс и создавался тогда, когда каждый пользователь был немного программистом, и следствие того, что cmd line удобен для автоматизации просто по своей архитектуре.
Поэтому Powershell, bash/zsh/ksh будут продолжать развиваться.

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

Comments

[Марат Нагаев]

Вижу 2 тезиса:
1. баш/powershell удобнее языка программирования для конкретных задач
2. условный питон через 10 лет не будет работать
с обоими тезисами я в общем-то согласен, однако это все проблемы отдельных реализаций (т.е языков)
Например - в питоне есть проблема с 2 и 3 версиями. В условном JS таких проблем практически нет (с годами совместимость не рушится). По 1 тезису согласен, например в яп нет удобного синтаксиса для пайпов (вроде ls | grep abc)
Но это тоже дело конкретной реализации, разве нет?
Можно добавить в условный js новые операторы, получить новый язык и радоваться жизни.

[Saboteur]

баш это язык оболочки.
Никто не пишет perl или python как оболочку операционной системы. Их пишут как языки программирования.
А шелл был разработан именно как оболочка с command line интерфейсом.

Можно добавить в условный js новые операторы, получить новый язык и радоваться жизни.

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

[Борис Сёмов]

Марат Нагаев, Можно, на зачем? Есть исторически сложившаяся, и при том, удобная среда. Под неё полно наработок. Она точно будет ещё очень долго присутствовать в дистрибутивах, и на её наличие можно будет полагаться.
Можно сделать подобную штуку с JS, но она не будет принципиально лучше - JS совсем не идеал. Это будет ещё один, из немалого количества мало кому нужных шеллов, который будет мало кто использовать.

А так никто не мешает для своего пользователя поставить любой другой шелл, и наслаждаться, многие вот zsh любят. Если поискать, можно и пару JS найти...

[Saboteur]

Вася Булка, cmd это в виндовсе. В линуксе изначально был sh/bash

[Vitsliputsli]

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 как скрипт автоматизации внутри дистрибутива.

[Марат Нагаев]

Борис Сёмов, вообще я не привязываюсь к конкретному языку, js привел в качестве примера.
На хабре есть статья: https://habr.com/ru/post/321652/
Там есть немного про shell. Если коротко: shell - весьма жуткая вещь с кучей проблем и костылей.

[Saboteur]

Vitsliputsli,

При этом bash и sh несовместимы.

Серьезно? =)
То есть вы хотите сказать, что шелл скрипт не запустится в bash, или вы в принципе понимаете значение слова "несовместимый"
Наличие парочки башизмов (и ведь реально, кроме test больше ничего нет), не делает их несовместимыми.

Назвать bash языком программирования у меня бы язык не повернулся,

Очень печально, что вы так смотрите на этот мир. Это язык программирования по всем определениям. И он по-своему прекрасен.

с точки зрения любого языка программирования синтаксис bash ужасен.

Отличный, понятный, простой синтаксис. То, что он не заточен под ООП, не отменяет прелесть баш.
Вы его с повершелл сравните, например.

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

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

Все ваши аргументы - исключительно личные предвзятости.

[Saboteur]

Марат Нагаев,

Там есть немного про shell. Если коротко: shell - весьма жуткая вещь с кучей проблем и костылей.

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

И про shell там написано человеком, который говорит не о том. На что он ругается? Что надо экранировать обратный слеш, если ищешь файлы у которых в имени есть обратный слеш? То, что это символ экранирования, и чтобы к нему нужно было обратиться его самого нужно экранировать для вас новость? Покажите как вы это будете делать в питон - тоже ведь надо будет писать \\.
При этом в пример приводится команда find, которая не является частью bash вообще. Претензии к выполнению команды на удаленном хосте, через ssh, что тоже не является проблемой bash, или покажите , как вы сможете это сделать "красиво" на другом языке программирования.
Причем он сам же оправдывается, что ЗНАЕТ как написать проще и удобнее (xargs), но умышленно пишет фигню, чтобы рассказать что экранировать надо и @ и \ (ну то есть все специальные символы, как будто в других языках программирования этого делать не нужно)
Все примеры проблем что там приведены - в большей степени высосаны из пальца, и практически ни один из них не связан напрямую именно с bash, больше с gnu tools

[FanatPHP]

Марат Нагаев, тут на самом деле ответ очень простой.
Перед тем как что-то хаять, или что-то предлагать изменить - это надо делать не с чужих слов и не после поверхностного знакомства.
Сначала любую вещь надо понять, поработать с ней, получить опыт. И только потом предлагать какие-то идеи по "улучшению". Если они ещё останутся

[Борис Сёмов]

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

Ну и ваш вывод просто не верен, что явно видно на практике, хотя бы по тому, что есть масса скриптов, которые можно было бы написать на любом интерпретируемом языке, или даже сделать бинарниками, в общем-то, но написаны они на bash, потому что это просто и удобно, а не жутко и костыльно... =)

[Vitsliputsli]

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

[Saboteur]

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

[Alex Wells]

Saboteur, и зачем нужна совместимость bash, если набор другого софта, без которого девопс как без рук, на каждом отдельном инстенсе - разный? Какой смысл от миллиарда устройств с bash, если на одном из них не будет wget?) Не проще ли зафорсить версии ВСЕГО софта, а не просто надеятся на обратную совместимость bash, раз это и так нужно делать? И делается то это элементарно - контейнеры. А тогда и обратная совместимость нахер не нужна (конечно, в рамках разумного), и использовать можно что угодно.

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

[Saboteur]

Alex Wells,

Не проще ли зафорсить версии ВСЕГО софта,

Нет конечно. Как вы это сделаете в принципе? Посмотрите какой процент на тот же питон3 перешли?
Посмотрите какой процент XP все еще крутится на десктопах.
А что делать с кучей устройств - телевизоры, роутеры, и другие устройства, для которых обновления уже давно не выпускают?

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

Какой смысл от миллиарда устройств с bash, если на одном из них не будет wget?)

А wget никогда не был частью баш, да и редко когда он поставляется с дистрибутивами из коробки, поэтому тру программисты на баш используют curl ;)

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

Да нет.
Проблемы bash зачастую связаны с непониманием архитектуры линукс, от которой он напрямую зависит. И да, в баш есть вещи, которые исторически сложились и хотелось бы их исправить, но в любом языке это есть.
Просто если хочешь писать на баш чуть больше hello world - ну так потрать хотя бы несколько недель на нормальное изучение, а не считай что достаточно 2 минуты погуглить. За 2 минуты погуглить можно найти готовое решение (и кстати из-за высокой совместимости, оно скорее всего будет работать, даже если его написали 10-20 лет назад), но не всегда будет понятно почему именно оно работает и почему надо делать так.

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

Поэтому, IMHO альтернативы башу - разве что zsh. Баш это и язык программирования и язык автоматизации и стандартная и дефолтная cli оболочка.

Если говорить об реальных современных альтернативах башу именно в его функционале, то нужно говорить о конкретных инструментах, которые действительно лучше - ansible/puppet/chef для оркестрации, или например Acronis вместо скриптиков с tar/gzip. И другие подобные штуки.
Но все эти подобные штуки - крупный софт специализированный софт, а не универсальное решение.
Зачастую платный или с неподходящей лицензией.

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

Но.
Банально, скопировать файл - проще в баш, чем в python и проще чем в джава.

Банально, работать в командной строке - проще чем в баш, чем в интерпретаторе питона.

Банально, написать stop/start скрипт - проще на bash. Даже в вашей java бутспринг под капотом запускает баш скрипт, который запускает java ;)

Поэтому полностью универсальной альтернативы башу, которая лучше чем баш - не существует и врядли будет существовать как минимум в обозримом будущем, особенно учитывая что доля *nix растет и в чистом виде и в андроид/harmony/macos.

[DevMan]

Saboteur, альтернативы есть: тот же zsh на голову выше bash.

но, в целом, я совершенно согласен с тобой: любой шел - самодостаточен.

[Vitsliputsli]

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

[Saboteur]

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

ООП бесполезная трата ресурсов, ведь все можно сделать через if и for

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

Но, действительно, спорить бесполезно с человеком, кто не писал ничего сложнее скриптов автоматизации

Ну так не спорьте с ними, вы же со мной общаетесь, или с кем-то другим?

Понимаю, что для сисадмина все разработчики занимаются фигнёй, ведь все можно просто и легко сделать в bash.

С чего вы так считаете?
Я утверждаю совсем не это. Я утверждаю, что баш - это отличный скриптовый универсальный язык программирования, который одновременно является дефолтной CLI оболочкой в *nix, и на нем удобно программировать и простые скрипты и чуть более сложные. Но пытаться реализовать ООП в баш, или предлагать вместо него использовать такие вещи как python/perl и другое в качестве альтернативы - это оверинженеринг.
Это вы принижаете возможности баш, упершись в единственный приведенный аргумент в виде реализации хранения переменных.

[Saboteur]

DevMan, Так я же про zsh и написал =)
если zsh станет дефолтной оболочкой во всех популярных дистрибутивах, вряд ли кто-то пострадает, а большинство вероятно даже не заметит разницы.

[DevMan]

Saboteur, она уже стала дефолтом в макоси.
но я как раз не спорю с тобой, а наоборот согласен.

[Alex Wells]

Saboteur,

Как вы это сделаете в принципе?

Контейнеры :)

А wget никогда не был частью баш

Вот именно) Как и миллион других инструментов. Не использовать ничего, кроме базового набора тогда?)

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

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

Банально, скопировать файл - проще в баш, чем в python и проще чем в джава.

Банально, работать в командной строке - проще чем в баш, чем в интерпретаторе питона.

Банально, написать stop/start скрипт - проще на bash. Даже в вашей java бутспринг под капотом запускает баш скрипт, который запускает java ;)

Я к тому и веду, что, имхо!!, это временно. Как я и сказал, джава уже наращивает мощности и копирование файла там становится настолько же простым, как и в баше. Только, опять же, джава легко тестируется, более удобна, легко шерит код между проектом и "скриптами" автоматизации, не использует никакие костыли.

[DevMan]

Alex Wells, только шелл уже есть в системе.
а чашку надо ставить.
и далеко не каждая система это переживёт.

[Saboteur]

Alex Wells,

Я к тому и веду, что, имхо!!, это временно.

Java не является тем, что ставится из коробки во всех дистрибутивах.
И то и другое - огромный оверинженеринг для вещей вроде копирования файла. Тут не нужна мощность языка. И джава - не интерактивна.

Чтоже касается контейнера -
Докер не является тем, что ставится из коробки во всех дистрибутивах, и в контейнере опять таки надо что-то запускать.
То есть вместо банального cp для копирования файла, ваше "мощное" решение - это установить докер, потом скачать базовый образ чего-то, потом запустить контейнер, потом придумать как в этом контейнере примаунтить все нужные диски, и потом внутри контейнера копировать?
Вам самому не смешно от этой чуши?

Только, опять же, джава легко тестируется, более удобна, легко шерит код между проектом и "скриптами" автоматизации, не использует никакие костыли.

В баше костылей столько же, сколько и в джаве, а то и меньше.
Баш тоже легко тестируется - +x и все
Непонятно что такое шарить код между проектом и скриптом автоматизации - скрипты на баш это просто код.

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

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

Ну вот, можете посмотреть на баш-скрипт посложнее: https://github.com/sfkulyk/jks-manager/wiki
код как код. Упрощенный для максимальной совместимости, можно было бы оптимизировать, но это не требуется - баш не про performance. Поэтому код написан так, чтобы джуниор мог разобраться.

[Alex Wells]

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

Saboteur,

огромный оверинженеринг для вещей вроде копирования файла
Вам самому не смешно от этой чуши?

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

Все это делается очень легко с помощью нормального языка. С bash это адская боль.

Баш тоже легко тестируется - +x и все

Я про автоматические тесты.

Непонятно что такое шарить код между проектом и скриптом автоматизации - скрипты на баш это просто код.

Ну, например в проекте есть код, вытаскивающий актуальную версию чего-то там с помощью какого-нить github SDK. Потом эта версия понадобилась в каком-то скрипте. Если проект и скрипты на одном языке - это элементарно шерится. Если на разных - проще вообще не шерить.

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

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

Именно поэтому в нормальной ситуации вы не ставите себе в облаке базу, а используете готовое облачное решение.

Да нет, не использую. Над таким "облачным решением" обычно ноль контроля - оно падает когда захочет, обновляется только руками в дешборде, отстает по версиям от self-hosted.

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

Зачем обновлять контейнер с httpd, если httpd это практически по дефолту уже установленный в системе сервис, и обновить его можно не косячным скриптом с контейнером, а штатным пакетным менеджером.

Затем что обновлять его нужно одновременно у девов, QA, на тестовых, на стейдже, на продакшене. На каждом хосте ручками ставить нужную версию? А она же еще совпадать должна!

Ну вот, можете посмотреть на баш-скрипт посложнее: https://github.com/sfkulyk/jks-manager/wiki

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

Возможно, если подобную програмулинку не нужно поддерживать, так как в ней минимальный функционал - оно и ок. Но так же не всегда)

[Saboteur]

Alex Wells,

Но давайте поговорим не о копировании файла, а, например, о билде и деплое проекта.

Простите, но какое отношение дефолтная оболочка имеет к билду и деплою?
Докер это вообще не для этого. Любой язык программирования - тоже не для этого
Для этого нужен не контейнер и не баш и не язык программирования в принципе, а любой CI инструмент - Дженкинс, тектон, тимсити, gitlab-ci и все другое - там и время записывается и пайплайны и все остальное. А вот уже под капотом может быть и баш и груви и докер и все что угодно. Но вы IMHO путаете цели и инструменты.

Я про автоматические тесты.

Автоматические тесты не имеют отношения к конкретному языку программирования.
Каждый уважающий себя язык программирования имеет свои библиотеки и инструменты для юнит тестов и автотестов, поэтому тут не должно быть некоего универсального языка. Это должно решаться средствами того языка, на котором пишется проект. Ну простые примеры - юнит тесты для js и java запускаются собственно их сборщиками - maven и npm. А если это более сложные тесты, то они могут запускаться на виртуалках или в докере CI инструментом.

Мне вот интересно:

Из банального:
- погрупировать таски
- записывать время выполнения каждой мелкой таски
- проверять что она не завалилась
- репортить все это в какой-нить слэк в конце
- делать ролбек в случае неудачи
- подчищать за собой остатки

Все это делается очень легко с помощью нормального языка. С bash это адская боль.

Вот каким именно нормальным ЯЗЫКОМ вы это решаете, как девопс?
Я это решаю в первую очередь CI/CD инструментом, в котором может использоваться и простые bash скрипты и сложные технические решения вроде GRP в оракле или kubernetes.

То есть ваш пример вообще нерелевантен.

Ну, например в проекте есть код, вытаскивающий актуальную версию чего-то там с помощью какого-нить github SDK. Потом эта версия понадобилась в каком-то скрипте. Если проект и скрипты на одном языке - это элементарно шерится. Если на разных - проще вообще не шерить.

А в чем проблема, если каждый инструмент будет лезть в github своим методом? Главное авторизацию настроить. дженкинс будет лезть своим git плагином, джава своей библиотекой, bash - консольной утилитой. В чем собственно проблема? Вы же не хотите тянуть еще один какой-то универсальный мощный современный язык в каждый проект?

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

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

Да нет, не использую. Над таким "облачным решением" обычно ноль контроля - оно падает когда захочет, обновляется только руками в дешборде, отстает по версиям от self-hosted.

Значит у вас нет потребности в стабильности крупной базы, если self-hosted достаточна. Опять таки, в большом проекте апгрейдиться на каждую минорную версию совершенно неподходящее решение.

Затем что обновлять его нужно одновременно у девов, QA, на тестовых, на стейдже, на продакшене. На каждом хосте ручками ставить нужную версию? А она же еще совпадать должна!

httpd обычно одной версии, и редко когда обновляется именно версия httpd.
Совпадать опять таки должна не всегда, httpd редко вызывает несовместимость, это же не php

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

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

[Alex Wells]

Saboteur,

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

Верно. И у bash нет нормальных тест-фреймворков.

Это должно решаться средствами того языка, на котором пишется проект.

Речь о тестировании самих bash скриптов. Понятно, что к проекту это не имеет отношения.

как девопс

Я не девопс) Я разработчик с малюсеньким опытом девопсинга)

Я это решаю в первую очередь CI/CD инструментом, в котором может использоваться и простые bash скрипты и сложные технические решения вроде GRP в оракле или kubernetes.

Конечно, да. Но тут либо CI/CD решает 100% задач, либо приходится допиливать что-то. И, опять же, редко когда удается допилить требя строчками bash скрипта.

Вот каким именно нормальным ЯЗЫКОМ вы это решаете

Ну вот помимо существующих CI/CD, с радостью попробую kotlin script.

А в чем проблема, если каждый инструмент будет лезть в github своим методом?

В том, что этот метод нужно поддерживать в двух местах, вместо одного? Насобирать три-четыре таких места и никто не захочет это трогать.

Апгрейд версии?

Да.

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

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

Значит у вас нет потребности в стабильности крупной базы, если self-hosted достаточна.

На моем рабочем проекте - к сожалению есть потребность, у нас aws aurora. И это ужасно, но абсолютно понятно - мы пожертвовали фичами и понятностью в пользу стабильности и авто-девопса. Но это крайние меры, а не дефолтный путь.

Опять таки, в большом проекте апгрейдиться на каждую минорную версию совершенно неподходящее решение.

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

Совпадать опять таки должна не всегда, httpd редко вызывает несовместимость, это же не php

... очень бредовый аргумент. PHP тоже обратно-совместим по большей мере, как и большинство инструментов. В новых версиях появляются новые фичи и фиксы. Их не использовать? А еще не все используют httpd и тут вообще вся идея рушится)

Попробуйте так стэк пообновлять у 50 девов и на 6-8 средах - желание повторять отпадет еще до того, как вы это первый раз провернете.

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

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

[Vitsliputsli]

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 специализирующего на запуске команд.

[Vitsliputsli]

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

[Saboteur]

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

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

$ A="echo B"
$ echo $A
echo B

То есть ваша константация факта - это заблуждение.

Верно. И у bash нет нормальных тест-фреймворков.

Конечно, да. Но тут либо CI/CD решает 100% задач, либо приходится допиливать что-то. И, опять же, редко когда удается допилить требя строчками bash скрипта.

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

Ну вот помимо существующих CI/CD, с радостью попробую kotlin script.

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

А в чем проблема, если каждый инструмент будет лезть в github своим методом?

В том, что этот метод нужно поддерживать в двух местах, вместо одного? Насобирать три-четыре таких места и никто не захочет это трогать.

А если у вас 5 микросервисов, у вас будет 5 мест или одно?
Непонятно что такое за разные места и в чем заключается сложность. Я редко встречал проекты, написанные один в один - как минимум бэк и фронт зачастую разные фреймворки, а то и разные языки программирования, вот уже два места вместо одного. И в чем собственно проблема?

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

Фиксы для базы, которые могут вызвать несовместимость данных - выводить автоматом не рекомендуется в принципе. При этом автоматизировать апгрейд на том же баше - да нет никаких проблем. В этой штуке автоматизация сложна в первую очередь на организационном уровне, а именно - когда делать апгрейд, сколько времени он займет (потребуется ли конвертация самих данных), будет ли даунтайм приложения, если все пойдет не так, сколько времени займет откат назад, и соответственно согласование этих этапов.
В первую очередь в апгрейде версии таких вещей как джава, версия ОС, базы данных и других third party вещей - это организационный момент, а не технический. Техническое обновление автоматизируется чем угодно, включая баш, ансибл, докер.. неважно.
Вот вы пишете на фреймворке, а к нему выходят те же обновления уязвимости. Как вы его обновляете каждый месяц? Или фреймворк вы так часто не обновляете, и почему-то считаете что уязвимости в базе важны, а в фреймворке нет?

Если вам в жизни удастся поуправлять самолетом, вы не станете пилотом.

Управлял, но почему я не могу стать пилотом - непонятно.

А вы пишите, что вполне нормально копировать все страницы памяти, для простейших операций.

Где я это пишу???

Но писать про это предлагая взамен полное копирование всех страниц памяти интерпретатора (fork) даже при элементарных операциях - это показывать полное непонимание на чем можно экономить

Хм. вы понимаете как работает форк и что именно копируется? Это же не к башу вопрос, это в принципе к архитектуре ОС. При форк страницы памяти не копируются.

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

Универсальность - обозначает то, что язык можно использовать для разных вещей, а не узкоспециализированных (как lua/scala). Баш достаточно универсален, другое дело, что он не такой мощный.

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

[DevMan]

Alex Wells,

я смотрю на это со стороны девопс

отлично – вам баш не очень и нужно.
а мне не нужны контейнеры для сетевых железок или для скрипта в сотню строк для автоматизации простой рутины.

[Alex Wells]

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

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

А ваши апгрейды базы не требуют доп. зависимостей? Вот прям никаких? На голом alpine все запустится? Не смешите.

Зависимости нужны почти всегда. Лично мне даже лучше, если это будет одна единственная джава машина (или не только она - котлин, вообще то, компилируется не только в джаву, можно и в обычный бинарник, как с джавой внутри, так и вовсе без нее), чем тонна непонятных бинарников на уровне системы непонятных версий и, как сказали выше, с непредсказуемым IO.

А если у вас 5 микросервисов, у вас будет 5 мест или одно?

Одно, конечно же. Либо один микросервис, либо одна общая библиотека.

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

Так очень малое кол-во кода как-либо шерится между фронтом и бэком. Это просто разные миры. Хотя, опять же, тот же kotlin-multiplatform позволяет компайлить куски кода одновременно и в джаву на бэк, и в джаву на андроид апку, и под айос, и под фронт. И да, это используют, дабы упростить и ускорить разработку, а так же свести риск проеба к минимуму.

Фиксы для базы, которые могут вызвать несовместимость данных

Это патч версии. Если сильно боитесь, можно поднимать снепшот, апгрейдить базу, запускать тесты и потом уже апгрейдится. И это спокойно можно делать на CI, автоматически по смене версии базы в каком-нибудь docker-compose.yml.

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

Да не будет никаких проблем, поднимая патч версию. А остальное - о чем я и говорю. Поднимать версию руками так точно никто не станет чаще раза в год. Если оно обновляется по указанной где-то там версии само, одновременно на всех енвайронментах и у всех девов - та хоть раз в месяц.

Вот вы пишете на фреймворке, а к нему выходят те же обновления уязвимости. Как вы его обновляете каждый месяц? Или фреймворк вы так часто не обновляете, и почему-то считаете что уязвимости в базе важны, а в фреймворке нет?

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

[Saboteur]

Alex Wells,

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

Никогда не говорите никогда ;)

А ваши апгрейды базы не требуют доп. зависимостей? Вот прям никаких? На голом alpine все запустится? Не смешите.

Обычно апгрейды самой базы не требуют никаких дополнительных зависимостей. Все зависимости которые нужны - они нужны для работы самой базы и уже установлены. А вот ставить дополнения и зависимости для "скрипта, который запустит обновлялку" - imho перебор.

чем тонна непонятных бинарников на уровне системы непонятных версий и, как сказали выше, с непредсказуемым IO.

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

Одно, конечно же. Либо один микросервис, либо одна общая библиотека.

То есть фронт и бек у вас всегда один микросервис? И написан на одном фреймворке?

Это патч версии. Если сильно боитесь, можно поднимать снепшот, апгрейдить базу, запускать тесты и потом уже апгрейдится. И это спокойно можно делать на CI, автоматически по смене версии базы в каком-нибудь docker-compose.yml.

Да не будет никаких проблем, поднимая патч версию. А остальное - о чем я и говорю. Поднимать версию руками так точно никто не станет чаще раза в год. Если оно обновляется по указанной где-то там версии само, одновременно на всех енвайронментах и у всех девов - та хоть раз в месяц.

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

Я не говорил про уязвимости) Я говорил про очевидные баги базы, вызывающие проблемы у конечных юзеров проекта.

Если существуют очевидные баги базы, которые вызвают проблему аж у конечных юзеров, зачем вы юзаете такую плохую базу...
Переходите на постгрес ;)

Да, если в фреймворке есть таковые и оно решено в новых версиях - мы поднимаем версию, конечно.

Зачастую смена версии фреймворка может потребовать неслабых изменений в коде.

И обновляем мы его меняя циферки версии в одном файле, diff на одну строчку :)

У вас очень, очень, очень простой проект.
Вдобавок вероятно нет аудита и возможность ставить что хочется из инета напрямую.

[Vitsliputsli]

Alex Wells,

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

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

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

[Alex Wells]

Saboteur,

Обычно апгрейды самой базы не требуют никаких дополнительных зависимостей. Все зависимости которые нужны - они нужны для работы самой базы и уже установлены. А вот ставить дополнения и зависимости для "скрипта, который запустит обновлялку" - imho перебор.

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

Все нужные для работы баша бинарники

Для баша? Или для типичных (опять же, типичных в моем понимании) скриптов на нем? Первое - это понятно, а второе - отписал выше)

То есть фронт и бек у вас всегда один микросервис? И написан на одном фреймворке?

Нет. Вы же спросили про "метод", я про него и ответил. Фронт и бэк априори не могут быть на одном фреймворке, но легко могут использовать библиотеку, написанную на одном языке.

Я не понимаю. Почему для вас баш - это обновление руками?

Ну не прям руками. Но и не автоматически. Опять же: есть у вас 50 девов и в придачу еще 6-8 стейдж/прод енвов. На каждом будете вручную запускать скрипт, даже если допустить, что он универсально выполнится на linux/macos/docker разработчиков и условный ubuntu/docker стейджов? А если через день найдется бажок и нужно будет откатить? Опять все руками?

Это, все таки, разные вещи. Если вас в команде 3 человека и у вас только стейдж и прод - ок, это терпимо. Но с любым более-менее большим проектом это совсем не работает.

плохую базу...

AWS Aurora mysql :) А если серьезно, бывает, не могу сказать, что база прям плохая. Можно перейти на aurora postgre, но это сложно на живом большом проекте)

Зачастую смена версии фреймворка может потребовать неслабых изменений в коде.

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

У вас очень, очень, очень простой проект.

Это не так. В нормальной разработке именно так и должно быть. Для обновления зависимостей во всех языках есть менеджер зависимостей, собирающий нужные версии нужных библиотек, под нужную платформу и в нужном порядке.

Вдобавок вероятно нет аудита и возможность ставить что хочется из инета напрямую.

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

[Alex Wells]

Vitsliputsli, https://docs.aws.amazon.com/AmazonRDS/latest/Auror...

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

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

[Saboteur]

Alex Wells,

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

окей, база обновляется без зависимостей.
Может быть джаве для обновления нужны зависимости?
Может быть докеру для обновления нужны зависимости?
ЧЕМУ кроме обновления OS нужны зависимости?
Ну не несите чушь. подавляющее количество софта при обновлении новых зависимостей не требует.

Для баша? Или для типичных (опять же, типичных в моем понимании) скриптов на нем? Первое - это понятно, а второе - отписал выше)

Не понимаю что отписано выше. gnu tools - популярные утилиты. ls, top, grep, ps, kill - понятно что без них мало что можно сделать в системе. Не понимаю какие у вас с ними проблемы. Любой язык программирования без библиотек - практически ничего не может делать.

Нет. Вы же спросили про "метод", я про него и ответил. Фронт и бэк априори не могут быть на одном фреймворке, но легко могут использовать библиотеку, написанную на одном языке.

Баш тоже может использовать библиотеку, написанную на том же языке.

Ну не прям руками. Но и не автоматически. Опять же: есть у вас 50 девов и в придачу еще 6-8 стейдж/прод енвов. На каждом будете вручную запускать скрипт, даже если допустить, что он универсально выполнится на linux/macos/docker разработчиков и условный ubuntu/docker стейджов? А если через день найдется бажок и нужно будет откатить? Опять все руками?

Ну значит вы не понимаете, что баш это не оркестратор. Можно запускать не вручную, а через jenkins, можно использовать ansible/chef/puppet и другие вещи. Зачем тащить баш именно туда, где уже есть популярные инструменты, которые НЕ являются другими "более современными" языками программирования, а именно инструментами оркестрации???

Это, все таки, разные вещи. Если вас в команде 3 человека и у вас только стейдж и прод - ок, это терпимо. Но с любым более-менее большим проектом это совсем не работает.

У меня ~10 только команд разработчиков и используется множество инструментов. И связующим клеем часто является или баш или питон, в зависимости от того, что нужно в данный момент.

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

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

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

Автоматические секьюрити чеки всегда работают на отлично?
Скажем в каком-нибудь фреймворке всегда есть куча 3rd party библиотек. И на одну из библиотек ругается секьюрити чек.
Что вы делаете - обновляете руками эту библиотеку в фреймворке, или обновляете весь фреймворк?
А если нет версии этой библиотеки без уязвимости (по словам вашего секьюрити чека), как вы обходите завалившийся чек?
И самое интересное, как это у вас все выполняется полностью автоматически?
Я уверен что регулярно приходится что-то делать руками.

[Alex Wells]

Saboteur,

подавляющее количество софта при обновлении новых зависимостей не требует.

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

gnu tools - популярные утилиты.

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

Понятно, что простенькие баш скрипты скорее всего будут работать везде. Но даже у этого нет никаких гарантий! Если у ls на макоси или у ls на ubuntu 10 какого-то одного флажка нет, потому что там ls кастомный или старой версии, то даже с "популярными" gnu tools ваш скрипт завалится.

Баш тоже может использовать библиотеку, написанную на том же языке.

Условная котлин библиотека не компилируется в баш и, обьективно, никогда не будет. А использовать такую библиотеку как executable вы не сможете, так как это библиотека, а не executable :/

Ну значит вы не понимаете, что баш это не оркестратор. Можно запускать не вручную, а через jenkins, можно использовать ansible/chef/puppet и другие вещи.

Справедливо, ок. Но это хак на хаке. Я вел к тому, что решения типа докер компоуза подходят сюда намного лучше, чем любая полу-ручная автоматизация.

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

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

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

Так я же везде указывал, что речь идет об патч, в крайнем случае - минорных версиях. Их автоматический апдейт возможен всегда, ибо +- все следует semver'у или его подобию.

Автоматические секьюрити чеки всегда работают на отлично?

А какая альтернатива? Вручную просмотреть все - невозможно. В современных проектах сотни, если не тысячи зависимостей, если считать вложенные. В каждую из них может влетать по 10+ коммитов в день.

Что вы делаете - обновляете руками эту библиотеку в фреймворке, или обновляете весь фреймворк?

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

А если нет версии этой библиотеки без уязвимости (по словам вашего секьюрити чека), как вы обходите завалившийся чек?

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

Если вдруг не повезло - руками апдейтим, конечно же.

И самое интересное, как это у вас все выполняется полностью автоматически?

Так речь вроде была про аудит. Фикс багов не часть аудита.

Я уверен что регулярно приходится что-то делать руками.

Угу. А еще нам приходится писать код oO. Надеюсь это не была попытка сравнить возможную на данный момент автоматизацию и невозможную.

[DevMan]

Saboteur, Alex Wells, Vitsliputsli, посоны, вас вообще утянуло в сторону от заданного вопроса и понесло в высокие материи.

а ответ же прост: устраивает баш - пользуй; не устраивает - пользуй более другое.

[Saboteur]

Alex Wells,

Я поэтому и уточнил, что мы взяли этот кейс для примера.

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

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

Ощущение, что у тебя 1+1=3. Баш универсален. Особенно для вызова внешних команд, таких как пакетный менеджер - он подходит лучше всего. Поэтому для любых обновлений - это лучший выбор.

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

Ничего не нужно.

Понятно, что простенькие баш скрипты скорее всего будут работать везде. Но даже у этого нет никаких гарантий! Если у ls на макоси или у ls на ubuntu 10 какого-то одного флажка нет, потому что там ls кастомный или старой версии, то даже с "популярными" gnu tools ваш скрипт завалится.

У любого языка есть свои кастомные штуки при работе в разных ОС.
И совершенно непонятно, почему наличие всего одного флажка вдруг вызывает завал скрипта. Этот флажок может и не использоваться, и в 99% неиспользуется, если ты пишешь скрипт с желанием сделать совместимо.
На джаве легко написать код, который не запустится в 1.8, или не запустится в макос. Раунд.

Условная котлин библиотека не компилируется в баш и, обьективно, никогда не будет. А использовать такую библиотеку как executable вы не сможете, так как это библиотека, а не executable :/

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

Я вел к тому, что решения типа докер компоуза подходят сюда намного лучше, чем любая полу-ручная автоматизация.

докер компоуз сам все обновляет?
Или вы про использование latest в докерфайле?
Или можете привести адекватный пример технического решения проблемы путем замена на более современный скриптовый язык?

Принимаем решение исходя из цены и выгоды обеих решений.

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

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

Обьективно, уязвимости находятся довольно редко.

Вне нашей текущей дискуссии, поменяйте ваш скан уязвимостей ;)

[Alex Wells]

Saboteur,

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

Ничего не нужно.

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

У любого языка есть свои кастомные штуки при работе в разных ОС.
И совершенно непонятно, почему наличие всего одного флажка вдруг вызывает завал скрипта. Этот флажок может и не использоваться, и в 99% неиспользуется, если ты пишешь скрипт с желанием сделать совместимо.

Ну понятно, что я имел в виду ситуацию, когда этот флажок используется, а не просто висит без дела. Да даже копируя простой tail --lines=100 из ответа стаковерфлоу, совсем не ожидаешь, что оно не работает на macos. Такие же ситуации у меня были с find, не помню точно что именно. Ничего сверхестественного, самые обычные флажки. И не работает.

На джаве легко написать код, который не запустится в 1.8

Конечно. Но мы же не ставим джаву системно, иначе пришлось бы и 1.6 поддерживать, авось у кого-то завалялась :)

или не запустится в макос.

Вы не правы, совсем. Языки прячут os-specific штуки за абстракциями. Добится неработоспособности какого-то кода на одной из платформ - очень и очень сложно. Нужно прямо хорошенько постаратся.

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

.. нет, не можете. То, что вы хотите, называется не библиотека, а целое консольное приложение. Что бы у нее была точка входа, парсер аргументов, вывод exit code, stdout и stderr. Это в разы дольше и сложнее, чем просто библиотека, которую можно использовать только как зависимость к другому проекту и никак иначе.

Или вы про использование latest в докерфайле?

Да почему latest то? Сменили конкретно указанную версию с 5.7.2 на 5.7.13, в образе дефолтно-запускаемый скрипт сделает все, что нужно. docker compose up убьет предыдущий контейнер, поднимет новый, тот запустит все что ему нужно. Если на енвайронменте еще старый код и он не умеет работать с 5.7.13, то и в компоузе будет старая версия и она не поднимется там, где это не нужно. Тоже самое если девелопер меняет бранчи и переходит с одной на вторую, может хоть 10 раз в день версию менять и происходит это за 15 секунд.

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

Не могу, к сожалению. Этот конкретный пример - вообще не место для скриптового языка. А другого примера не знаю, но уверен, что у скриптовых языков есть применение. И именно о таких местах надо было говорить изначально)

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

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

А вот такие банальные вещи как обновление стэка - уже довольно давно прекрасно и легко автоматизируется. Как и многое другое. Не надо сравнивать одно с другим.

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

Согласен. Потому что примеры идиотские. Нужен нормальный, который не заменяется другими инструментами.

[Saboteur]

Да даже копируя простой tail --lines=100 из ответа стаковерфлоу

Покажите мне этот ответ из стек оверфлоу. Я очень удивлюсь, чтобы кто-то писал --lines=100 вместо -n 100 (а -n поддерживается в макос).

Вы не правы, совсем. Языки прячут os-specific штуки за абстракциями. Добится неработоспособности какого-то кода на одной из платформ - очень и очень сложно. Нужно прямо хорошенько постаратся.

Обратиться к c:\ ?
Или вы так не делаете? А почему? А может потому что изначально пишете код платформонезависимо?
Так а почему в баш не можете так делать и приводите платформозависимые примеры с --lines=100 ?

.. нет, не можете. То, что вы хотите, называется не библиотека, а целое консольное приложение. Что бы у нее была точка входа, парсер аргументов, вывод exit code, stdout и stderr. Это в разы дольше и сложнее, чем просто библиотека, которую можно использовать только как зависимость к другому проекту и никак иначе.

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

Не могу, к сожалению. Этот конкретный пример - вообще не место для скриптового языка. А другого примера не знаю, но уверен, что у скриптовых языков есть применение. И именно о таких местах надо было говорить изначально)

Так если не можете привести пример, на чем основывается тогда уверенность, что баш давно пора заменить на другой более мощный и современный язык?
У скриптовых языков у всех есть отличное применение, но баш в качестве универсального языка и оболочки - пока что самый удобный, и альтернативы у него, как я уже писал - ksh или zsh

[Alex Wells]

Saboteur,

Покажите мне этот ответ из стек оверфлоу. Я очень удивлюсь, чтобы кто-то писал --lines=100 вместо -n 100 (а -n поддерживается в макос).

Спасибо) Но это всего-лишь пример.

Обратиться к c:\ ?
Обратиться к c:\ ?
Или вы так не делаете? А почему? А может потому что изначально пишете код платформонезависимо?
Так а почему в баш не можете так делать и приводите платформозависимые примеры с --lines=100 ?

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

На примере того же tail все по-другому. tail под linux и tail под macos - может быть вообще двумя разными бинарниками, написанными на разных языках, в разных репо, разными разработчиками с разным, но схожим набором функционала. А еще могут тупо стоять разные версии. Шанс что что-то сломается - в разы выше. И он есть даже с теми же gnu tools, а какой шанс, что сломается какой-нить mysql-client? redis-cli? Огромный. Могут легко между версиями поубирать флажки, подобавлять новых, поменять вывод, переназвать команды.

И тут можно запускать bash в контейнере, но тогда вообще весь профит пропадает, ибо тогда можно запускать что угодно.

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

Ну да. На каждую либу и метод - по джарнику писать? А если вывод сложнее, чем exit code 1/0? А если нужно аргументы передать, будете парсить ввод? Как костыль - ок, но к хорошему решению этому далеко.

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

В том что есть другие, более современные и мощные скриптовые языки. Логично же) Так же как языки и фреймворки заменяются другими, хоть они прекрасно работают дальше, так и тут баш можно заменить в тех местах, где скриптовый язык вообще нужен в первую очередь.

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

Ну тут наши мнения сильно расходятся. У современных языков есть вся мощь: асинхронность, параллельность, экосистема, синтаксис. Все это далеко не всегда нужно. Может даже почти никогда не нужно, я не знаю. Но когда оно нужно, вы все равно будете писать отдельную софтинку на другом языке, даже если используете ее в одном скрипте в одном месте.

[Saboteur]

Alex Wells,
Спасибо) Но это всего-лишь пример.

На примере того же tail все по-другому. tail под linux и tail под macos - может быть вообще двумя разными бинарниками, написанными на разных языках

наверное потому что linux и macos это разные ОС, но при этом обе системы посикс-совместимые.

Могут легко между версиями поубирать флажки, подобавлять новых, поменять вывод, переназвать команды.

Давайте так. Все мои попытки вам что-то пояснить приводят к тому, что вы говорите "ну это всего лишь пример, это всего лишь предположение".
Давай если будешь еще что-то писать в этот и так уже длинный тред, ты будешь приводить конкретные примеры, с конкретными несовместимостями. Потому что это реально надоедает каждый раз опровергать ваши предположения. Они ж так никогда не закончатся, и при этом еще ни одно не подтвердилось.

Ну да. На каждую либу и метод - по джарнику писать? А если вывод сложнее, чем exit code 1/0? А если нужно аргументы передать, будете парсить ввод? Как костыль - ок, но к хорошему решению этому далеко.

Чем плохи конфигфайлы? При этом их даже не обязательно менять, можно просто оверрайдить значения через переменные окружения (скорее всего об этой фиче в java вы не знаете).

Ну тут наши мнения сильно расходятся. У современных языков есть вся мощь: асинхронность, параллельность, экосистема, синтаксис. Все это далеко не всегда нужно.

В том-то и дело, что для CLI оболочки это не нужно совершенно. Нужна стабильность, универсальность, хорошая интеграция в первую очередь с ОС, а не со сторонней разработкой.

Но когда оно нужно, вы все равно будете писать отдельную софтинку на другом языке, даже если используете ее в одном скрипте в одном месте.

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

Но опять таки - в качестве shell, в качестве языка для администрирования и автоматизации простой рутины, в качестве клея для миллионов CLI утилит, внутри различных инструментов по CI/CD и так далее - bash/ksh/zsh - это идеальный инструмент в *nix, и он настолько комфортный, что пока что нет даже смысла с нуля писать что-то другое. Хотите развития - zsh это то, куда сейчас идет линукс шелл официально. Возможно лет через 10 он будет дефолтной оболочкой во многих дистрибутивах, ибо обратная совместимость у него полная.
В Windows так сложилось, что рулит не сообщество, а MS, и там рулит powershell, который значительно сложнее по синтаксису, поэтому он многим не нравится. Но да, он мощный, с кучей интеграции из коробки. Вот только простые вещи на нем делать сложно, поэтому часто параллельно с ним юзается либо совсем убитый старый cmd либо ставят что-то рядом, типа bash.

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

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

Answer 2

[FanatPHP]

Вопрос одновременно дебильный и нормальный.
Автор просто не может нормально словами написать, чего хочет.
Для современного поколения, воспитанного ютубой, это нормально.
Если бы вопрос можно было задать с помощью слов "гы-гы", "круто, чувак" и смайликов, то у него бы все получилось.
А пока приходится использовать интеллект на принимающей стороне, чтобы понять, что он там мычит.

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

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

Так что да - или легаси, или тупо адекватность задаче.

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

Comments

[FanatPHP]

shellnet, ой, а на тостере оказывается красноглазики с лора есть! какие забавные :)

[Vitsliputsli]

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

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

[FanatPHP]

Vitsliputsli, я на вопрос отвечаю. который там, наверху. написан

[Vitsliputsli]

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

[FanatPHP]

Vitsliputsli, ну не знаю, я не не понимаю как это можно понять по- другому. просто баш - это и оболочка и язык. и автор, как я думаю, спрашивает про второе.
и одной из причин использования bash scripting language - это степерь интеграции с command shell, которой не добиться из других языков программирования, несмотря на обертки.

[Saboteur]

FanatPHP, bash это не язык, это просто реализация posix shell оболочки, в котором есть даже несовместимые с posix вещи, как и в zsh, но обратно bash полностью совместим, и на текущий момент является наверное самой популярной и дефолтной оболочкой в большинстве дистрибутивов. Поэтому часто пишут bash, подразумевая sh

[Марат Нагаев]

FanatPHP, на самом деле я не очень хорошо знаю сам шелл, похоже
для меня шелл - это командный интерпретатор типа REPL.
вводишь команды, а они обрабатываются, прямо как в обычных яп.
Так чем оболочка отличается от языка?

[FanatPHP]

Saboteur, хорошо, если я вместо bash scripting language напишу sh-compatible command language, ваш перфекционизм будет удовлетворён?

[FanatPHP]

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

[Saboteur]

Марат Нагаев, в первую очередь тем, что оболочка - это программа для связи пользователя и компьютера.
В питоне или перле пользователь тоже может переходить в разные директории, смотреть что там есть и запускать программы. Но мне кажется это будет неудобно.
Просто оболочки бывают и графические и текстовые, включая CLI

[Vitsliputsli]

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

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

[AVKor]

Saboteur,

Поэтому часто пишут bash, подразумевая sh

Наоборот.

[FanatPHP]

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

Использовать как shell язык программирования просто избыточно

Мне тоже так кажется, но это-то и надо объяснить автору вопроса. Когда он определится, наконец, а что за вопрос он хотел задать-то

[Марат Нагаев]

FanatPHP, я про сам язык говорю
если я правильно понимаю у нас есть язык баш, т.е набор команд, а есть оболочка, куда мы эти команды вводим
зачем нужна оболочка - понятно, вопрос зачем нужен такой язык как баш
ведь оболочки есть и для других языков (repl), а эти самые языки можно просто допилить чтобы использовать их вместо языка шелла
тогда нас ждет чудесный мир, в котором нет баша из-за его ненужности: его задачи возьмет на себя general-purpose язык вроде питона
ну точнее он будет нужен, но только для легаси

[Stalker_RED]

Марат Нагаев, можете считать, что вы уже в этом чудесном мире. Смело пользуйтесь пайтоном или перлом, или что вам там удобнее, а баш пусть остается для совместимости с легаси.
Вербуйте людей на свою сторону. Соберите команду евангелистов, и запустите информационную компанию.

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

[Vitsliputsli]

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

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

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

[FanatPHP]

Марат Нагаев, ну значит я правильно понял ваш вопрос. И ответ читайте выше.
Я могу лишь добавить что язык программирования по определению является вторичным по отношения к командной оболочке. Главное в базе - все-таки возможность запускать команды и позволять им взаимодействовать друг с другом. Если вы попытаетесь вкрячить этот функционал в какой-то из языков программирования общего назначения, вы испортите и оболочку, и язык.

Но если вам так уж хочется, то разумеется, есть и оболочки где языком программирования является питон. Берите https://habr.com/ru/post/429892/, изучайте так же поверхностно, как изучили баш, и пускайтесь в фантазии о чем-то ещё.

[Saboteur]

cshell вот был вполне совместим с языком программирования С, но оказался невостребованным из-за чрезмерной сложности.

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

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

Вот навскидку простой вопрос - баш для пользователя и баш, которым выполняется еще один скрипт. Скрипт по нажатию Ctrl-C прерывается, а у просто при работе в командной строке Ctrl-C работу пользователя не прерывает. Кто задумывался где это зашито, и что нужно сделать, чтобы такое работало в питоне?

[Vitsliputsli]

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

[Saboteur]

Vitsliputsli,

просмотр истории команд выполняется внешней утилитой history

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

Про Ctrl+C это не проблема, но кто-то должен продавить опцию запуска того же питона без возможности его прервать по ctrl-C, и внедрить это в глобальный репозиторий.

Все эти "тривиальные задачи" кто-то должен согласовать, сделать, закоммитить и распространить. И понятно что нет смысла этим заниматься, если есть bash, про это я и говорю. А таких "тривиальных задач" там под капотом тысячи.

[Vitsliputsli]

Saboteur,

баш хранит историю команд в памяти и в файл ее скидывает только при выход

да, согласен, именно так.

Про Ctrl+C это не проблема, но кто-то должен продавить опцию запуска того же питона без возможности его прервать по ctrl-C, и внедрить это в глобальный репозиторий.

Не нужно ничего продавливать. Как правило, языки умеют обрабатывать сигналы ОС. Просто нужно в коде описать обработчик сигнала (в python это pcntl_signal), и в нем задать, что ничего не делать при Ctrl+C. Т.е. там все уже есть.

По "тривиальным задачам" именно так, нет смысла этим заниматься.

Answer 3

[DevMan]

Марат Нагаев,

зачем нужна оболочка - понятно, вопрос зачем нужен такой язык как баш

да непонятно вам ничего: bash (как и любой другой unix–shell) – не отдельный язык, который специально устанавливается, это и есть командная оболочка. со встроенными возможностями скриптования (которые являются "примитивным" ЯП и которые отличаются по возможностям между разными оболочками).

да можно не использовать эту возможность, а устанавливать жс или питон или руби или еще что–то и пользоваться их возможностями.
но:
1. не может быть речи о переносимости без зависимостей, далеко не всегда нужных.
2. далеко не всегда возможно (например, на встраиваемых системах).

Answer 4

[Дмитрий]

Попробуйте сами поработать интерактивно и, надеюсь, все сразу станет понятно:

sudo useradd -m perluser -s /usr/bin/perl && sudo -u perluser -i

sudo useradd -m phpuser -s /usr/bin/php && sudo -u phpuser -i

Comments

[shurshur]

В книжке Learning Perl (с ламой) приводили пример получения shell пользователя по его имени, и там было написано что-то вроде: "Там будет /bin/sh, или /bin/csh, или даже /usr/bin/perl, если вы большой оригинал".

Answer 5

[Adler]

Забивать гвозди можно и микроскопом, но молотком все таки удобнее...

Answer 6

[Sand]

bash нужен для интерактивного взаимодействия с системой без графического интерфейса - типа cmd или ps в винде. Не говоря уже о том что bash может использоваться как скриптовый язык. Если Вы не знаете зачем нужен bash - может и вопрос этот поднимать бессмысленно?

Comments

[FanatPHP]

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

[wisgest]

типа cmd или ps в винде.

А зачем cmd и ps в винде?

Answer 7

[Adamos]

Вот тот редкий случай, когда нужно вспомнить, что Линукс - это GNU/Linux.
Shell+GNU - это, по факту, и есть высокоуровневый ЯЗЫК для работы с ОС.
Гораздо лучше приспособленный к этому, чем любой из универсальных.

Answer 8

[Линуксоид]

Нельзя ставить знак равенства между командной оболочкой операционной системы и интерпретатором языка программирования работающим по принципу REPL (Read Evelute Print Loop)...

Answer 9

[Валентин]

В общем-то есть шел с питоном, но тут дело в том, что "нельзя просто взять и ..." Вот, я помню, что кто-то делал шел с питоном, но я даже не помню названия. Потому что зачем он мне? Я знаю Bash. Ко мне придет учится молодой человек - я ему буду показывать, что сам умею. И он в итоге тоже научится Bash'у. Ну вот как-то так это много лет уже и тянется.