Баш, питон... А исполняемые C++ сорцы с шебангом видали? :)

tcc -run вроде еще до изобретения перфокарт был

А в TempleOS юзается «священная сишка» для скриптов, написания приложений.

Ну тут не tiny, а полновесная зверюга с полным функционалом. На C скрипты не попишешь, а на современном C++ уже вполне: всё копируется-перемещается по значению, что строки, что пути. С памятью бодаться не надо. Практически скриптовый язык, только быстрый как понос. :)

И ещё я сомневаюсь, что в tcc реализованная мною фича с шебангом и рекомпиляцией по запросу есть из коробки.

Практически скриптовый язык, только быстрый как понос. :)

И статически-типизированный, last but not least.

рекомпиляцией

TCC ядро линукса за пару секунд компилирует, лол.

На C скрипты не попишешь

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

TCC ядро линукса за пару секунд компилирует, лол.

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

он это прямо из загрузчика во время загрузки может делать.

Эм... Ну я уже понял, что залез со свиным рылом в калашный ряд, но по процитированному - НАФИГА?!

НАФИГА

Ну вот такое развлечение у автора.

А ещё он qemu основал, ffmpeg, jslinux. И доказал, что терабайтные диски — не только для порно. Интересные у него развлечения, в общем.

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

Поправлено.

Можно только позавидовать.

кидай на щитхаб, пили документацию для самых маленьких и не очень умных... тема скриптов на с/с++ периодически всплывает

и да, есть ли кэширование уже скомпилированного кода? если да - есть ли проверка на внесённые изменения и инвалидация кэша?

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

и да, есть ли кэширование уже скомпилированного кода? если да - есть ли проверка на внесённые изменения и инвалидация кэша?

Естессно! По mtime. Строчка «Recompiling...» в первом запуске и её отсутствие во втором как бы намекает.

кидай на щитхаб, пили документацию для самых маленьких

Хорошая идея. Ща. :)

Отныне в гробу я видал этот ваш баш.

Т.е. ты не знал про linux_binfmt или ты научил C++ работать с пайпами popen без горождения бесчисленных проверок результатов?

25к строк компилирует у меня за мгновение (i5), пол года назад так было, на deb8.

Т.е. ты не знал про linux_binfmt

Не знал. Щас глянул по диагонали и не понял: зачем там какие-то пляски с /proc, когда шебангом всё решается без участия ядра?

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

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

Не знал. Щас глянул по диагонали и не понял: зачем там какие-то пляски с /proc, когда шебангом всё решается без участия ядра?

linux_binfmt это та часть ядра, которая понимает по сигнатуре в начале бинарника, что нужно запустить интерпретатор указанный после #!, либо выполнять как elf бинарник. Так же можно указать, например, mz для запуска PE бинарников через wine.

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

Нет, не понял. То, что ты городишь противоречит KISS. Идея bash в том, что можно перенаправлять вывод между несколькими бинарниками, минуя написание одного огромного бинарника. Скорость исполнения самого скрипта в таких задачах пренибрежительно мала по сравнению с временем работы бинарников. Т.е. люди не писали условные init скрипты на C++ не потому, что были тупые, а потому что C++ сильно усложняет задачу и может привести к утечкам/уязвимостям на ровном месте.

И доказал, что терабайтные диски — не только для порно

А что у Беллара по терабайтным дискам было? Я пропустил.

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

https://github.com/dimgel/cpp-linux-scripts

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

А вообще, любопытная задачка. По ощущениям, вполне возможно представить пайп в виде графа (аналогично AST), все ошибки бросать исключениями и ловить их внутри метода run() корневого узла. Никаких «бесчисленных проверок». И синтаксис вполне компактный можно сообразить. Если вдруг приспичит (потребуется скрипт и с кучей логики, и с пайпами), нарисую и выложу в ту же репу.

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

зачем её компилить каждый раз при вызове?

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

непонятно, в чём «скриптовость» компиляции сишных сорцов

Скриптовость в том, что теперь компилировать вручную не надо, оно само. :) А «гораздо читабельнее» - уже огромный плюс. Не единственный: ещё гораздо быстрее и гораздо надёжнее.

но это не скриптовый язык

И хорошо. :) «Скриптовый язык» это синоним чего-то матерно-убогого. :)

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

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

Т.е. люди не писали условные init скрипты на C++ не потому, что были тупые

Отчасти, а в основном потому, что я языки в бородаты годы были слабы.

а потому что C++ сильно усложняет задачу

В параллельной вселенной.

и может привести к утечкам/уязвимостям на ровном месте.

Мифология.

если ты хочешь «сложную логику», то можно написать утильку и скомпилить один раз. зачем её компилить каждый раз при вызове?

С этим есть какие-то проблемы? Нет.

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

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

Да. В ROOT, кажись, был встроенный интерпретатор плюсов.

Согласен, bash - штука неудобная. Но иногда приходится его использовать к сожалению.

Удачи тебе в ожидании окончания компиляции при использовании шаблонных библиотек, например, для поддержки regexp.

Отныне в гробу я видал этот ваш баш.

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

Отныне в гробу я видал этот ваш баш.

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

Даже тупо отрезать расширение у файла на плюсах гораздо проще

$ man bash
       ${parameter%word}
       ${parameter%%word}
              Remove matching suffix pattern.

Проще?

$ FN='example.txt'
$ echo ${FN%.txt}
example
$ echo ${FN%.*}
example

А насколько транспортабелен будет многофункциональный скрипт на С с подвязкой кучи разных библиотек ??
параметры запуска того же dd не менялись последних лет 40.
А функции и хидеры потихоньку плывут за веяними авторов :(

Баш не нужен. И тем более сишка. Скрипты нужно на питоне писать.

Кстати, можешь тогда еще поиграться с LibClang: https://clang.llvm.org/docs/Tooling.html

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

А что у Беллара по терабайтным дискам было? Я пропустил.

Он в 2009 много цифр числа пи посчитал, вроде как рекорд того времени.

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

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

так там установочный скрипт на полторы сотни Мб, мда.

Обычное дело для shell archives. Когда-то Java так распространялась.

как будто динамическая типизация есть благо

в каменты созываются ужаленные С++ом в жёппу и умученные от С++а.

теперь это трэд анонимных жертв С++а. ждём историй из жизни, как С++ изнасиловал вас в детстве, заставлял писать говнокод и городить шаблоны в шесть этажей.

Скрипты нужно на питоне писать.

Кому нужно - те пишут. На голом Питоне таки неудобно с пайпами. Да, есть работы на эту тему, но всё же, если в скрипт в основном представляет собой клей, то Питон вряд ли лучший выбор. xonsh вот интересен, но там не чистый питон опять таки.

непонятно, в чём «скриптовость» компиляции сишных сорцов.

Такая же, какая и у баша

ЛПП.

Не нужно собирать

Ой ли? Перечитайте ОП.

что-то делать с бинарниками

?

пересобирать руками по 10 раз при изменении

make? Не, не слышал.

Отныне в гробу я ( dimgel) видал этот ваш баш.

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

+1.

Я догадывался, что есть подвох.

как будто динамическая типизация есть благо

Для некоторых типовых задач однозначно даёт профит. Не хочешь добавить её в «кисий» ЯП?

как будто динамическая типизация есть благо

Это однозначное зло, на что я собственно вполне толсто и намекаю.

Практически скриптовый язык, только быстрый как понос. :)

И статически-типизированный, last but not least.

А чем это лучше окамля?

А ещё вилки! Вилки - абсолютное зло. Пиво ими хлебать трудно, а глаз чесать вообще опасно!

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

Мои собственные скрипты тривиальны, для сложных задач я чё посерьёзнее завожу. Потому что категорически влом продираться через идиотский синтаксис что условий, что циклов, что ${переменных$@#&^#$ с кучей заумных операций над ними}, что регулярок которые у здорового человека свои, у баша свои, у седа свои, у грепа... впрочем, у грепа есть опция -P.

За каждой, КАЖДОЙ @#^$Ь ерундой приходится в гугл лезть, потому что запомнить всю эту дичь невозможно. Если оно - только ради красивых пайпов...

Ну вот например, если настаиваете. Изобразил однажды прикола ради чтобы посмотреть на температуру проца под макс. нагрузкой. Полагаю, на std::thread было бы даже короче: как минимум потому что при завершении главного потока остальные сами бы сдохли.

$ cat ~/bin/load-all-CPUs.sh 
#!/bin/sh

CPUs_minus_1=$((`nproc` - 1))
#declare -A PIDs=()
PIDs=()

function clean_up {
        for i in `seq 0 $CPUs_minus_1`; do
                kill ${PIDs[$i]}
        done
        exit
}

for i in `seq 0 $CPUs_minus_1`; do
        nice bash -c 'while true; do :; done' &
#       PIDs[$i]=$!
        PIDs+=($!)
done

trap clean_up SIGHUP SIGINT SIGTERM

for i in `seq 0 $CPUs_minus_1`; do
        wait ${PIDs[$i]}
done

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

Для некоторых типовых задач

вот именно.

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

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

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

Более того, в 99% случаев шаблоны используются только чтоб обойти статическую типизацию для случаев когда алгоритм общий и отличается только на константы. Пример: std::map. Вот реально там отличия одного мапа от другого - это размер одной ноды, смещение в ней key и value, и адрес функции сравнения ключей. в более общем случае, там надо еще держать 32 байта под std::function. но опять же, даже ассемблерный код 1-в-1 с разницей на константы.

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

ЛПП.

Показательно.

Ой ли? Перечитайте ОП.

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

make?

Мусор убогий

Не, не слышал.

Я понимаю, что ты мне пастишь рандомные базворды, но всё же.

Во-первых, чем твоё убожество отличается от вызова компилятора? Ничем.

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

Третье. Колхоз-сборка - убожество в виде убожества. В нормальная виде никакая «сборка» не нужна.