Язабан

Да ладно, лучше по делу чего скажи.

Bash плох для всего, что больше условной сотни строк?

Отвечу примером, grub-mkconfig - больше трехсот строк. В /etc/grub.d почти каждый больше трехсот строк.

ну на баше недавно клиента для гит-системы написали…

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

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

ну на баше недавно клиента для гит-системы написали…

Так это был какой-то задрот, который на спор писал. Возможно, деньги выиграл. Такой и на ассемблере гит напишет…

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

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

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

Особенностью bash/sh является разбиение на лексемы после подстановки переменных, это многих сбивает с толку.

Ну и самой важной причиной огромного количества жалоб на bash является повальное и безудержное неосиляторство. Если уж внутри dhcp-client говнокод на sh,то от топикстартера тем более не стоит ожидать ознакомления с man bash. Вилкой в глаз не попадает и ладно.

Ну давай покормлю. Вот тебе набор статей о том, что в баше не так: https://www.oilshell.org/blog/tags.html?tag=shell-the-bad-parts#shell-the-bad...

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

где тег bash?

Особенностью bash/sh является разбиение на лексемы после подстановки переменных, это многих сбивает с толку.

Это особенность почти (или вообще?) всех командных оболочек, и ещё языка tcl.

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

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

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

Почему Bash плох для всего, что больше условной сотни строк?

При чём тут количество строк? Язык может быть плох/хорош для определённого рода задач, но не для объёмов кода.

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

Блин, ты серьезно?

https://ru.wikipedia.org/wiki/Интерпретируемый_язык_программирования

https://ru.wikipedia.org/wiki/Компилируемый_язык_программирования

К чему ты заваливаешь меня терминологией? Питон тоже интерпретируемый язык. Ничего что Youtube написан на нем?

в баше нет ооп

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

Далеко не факт. Когда говорят что «У нас весь хайлоад на питоне» то это значит «У нас весь хайлоад на Си с привязками питона для бизнес логики»

и ещё языка tcl

Интересно(на самом деле нет), что заставило тебя 4.2

Youtube - Written in:

Python (core/API), C (through CPython), C++, Java (through Guice platform), Go, JavaScript (UI)

Core означает ядро - основной код.

Это лишь детали реализации, к самому языку мало имеющие отношение. Можно и для баша компилятор написать, и для си интерпретатор.

Нет не совсем, например оригинальный CPython предварительно компилируется в байткод, а PyPy имеет JIT-компилятор.

Не понимаю. Что вы имеете ввиду?

Особенностью bash/sh является разбиение на лексемы после подстановки переменных, это многих сбивает с толку.

Это особенность почти (или вообще?) всех командных оболочек, и ещё языка tcl.

4.2

Что вы имеете ввиду?

В tcl сначала разбиение на слова, а потом уже подстановка переменных - ровно наоборот относительно bash

bash - это вообще не язык, это shell.

А, спасибо, я всё понял.

tcl:

set a pu
set b "ts Hello!"
# не работает
$a$b

bash:

a=ec
b="ho Hello!"
# выведет Hello!
$a$b

А я думал, что tcl в этом случае сработает как баш.

я думал, что tcl в этом случае сработает как баш

Нет, в tcl это нормально сделано. Но что-то большое писать всё равно неудобно

не стоит юзать Bash, если код программы займет больше сотни строк

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

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

 % wc -l /usr/sbin/freebsd-update | awk '{print $1}'
3395
 % head -n1 /usr/sbin/freebsd-update
#!/bin/sh

// В FreeBSD /bin/sh не является симлинком на Bash.

Кто больше? ☺

Из-за ужасного синтаксиса

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

program some params ... |
other more params |
...

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

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

У тебя ООП гойловного мозга

Ну хз, у нас в slitaz полно скриптоты на баше (точнее мы на busybox sh ориентируемся) и всё вроде норм.

в баше нет ооп???

Чем файл на диске не класс а программа не объект? Чем ls не ClassPropertiesLister, man – ClassDocumentationViewer, grep - MessageFilter, сам bash не InteractiveObjectFactory, итд?

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

Вот портеж, как я понимаю, написан в основном на питоне, с небольшими вставками из баш-портянок.

загуглил is bash oop, мне понравились результаты, считаю что я прав

wc -l /usr/sbin/freebsd-update | awk '{print $1}'
3395
Кто больше?

Ну мой yacc (pre-bison) парсер в bash-скрипт. Реализация jq на bash jq.sh как раз на bash и чуть больше. :)

wc -l jq.sh 
3436 jq.sh

на bash

А если переписать на POSIX Shell, будет ещё больше. ☺

У меня (и моих, и тех, что идут искаропки в ОС) нет скриптов на Bash. Но вот не уверен, что Bash мои скрипты сожрёт даже в режиме совместимости… а вот шелл из busybox должен (за исключением, наверное, использования внешних BSD-специфичных команд и/или их аргументов).

Хах. Щенок.

https://github.com/Winetricks/winetricks/blob/master/src/winetricks

Но вот не уверен, что Bash мои скрипты сожрёт даже в режиме совместимости

Но этим не стоит гордиться.

а вот шелл из busybox должен

Если там нет обхода ошибок самого dash, то bash точно прожуёт.

Вот портеж, как я понимаю, написан в основном на питоне, с небольшими вставками из баш-портянок.

„Portage“ в значении запускалка ebuild-ов написана на python. А portage в значении сами ebuild-ы вместе с их запускалкой и вместе со всем всем всем - написаны на sh/bash с библиотеками/eclass на том-же диалекте sh/bash что и сами ebuild-ы и эту всю еруду „жрёт“ python с его gil а в результате всё закономерно стоит раком.

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

winetricks

Совсем забыл про winetricks, да.

Но этим не стоит гордиться.

Ну, у меня линуксов уже давно нет (по крайней мере там, где я гоняю свою скриптоту), потому это не целевое окружение.

dash

обхода ошибок

Эээ… Я пишу скрипты под FreeBSD, я их даже не тестирую в Linux, потому об обходе ошибок ничего не знаю (знаю, но мне плевать). ☺

Эээ… Я пишу скрипты под FreeBSD

Я, конечно, фрюху уже несколько десятилетий плотно не видел, хоть и таки чинил недавно, но быстро. Но таки в курсе, что у неё идиосинкразии на bash нет, вполне себе ставится.

у неё идиосинкразии на bash нет, вполне себе ставится

И я не совсем хейтер:

 % pkg query '%n-%v' bash
bash-5.0.11

(идёт зависимостью к password-store)

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

уже несколько десятилетий плотно не видел

Чего-то глобально нового совсем мало.