Как ты себе это представляешь?

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

#!/bin/sish
$peace=$1;
if ( $peace == "duke" ) 
   {
        printf ("\npeace door ball\n");
        exit(1);
   }

Чего-то на Perl смахивает =))) Но принцип ты понял.

Чего-то на Perl смахивает

Угу. Меня бы больше приколол скриптовый язык со строгой типизацией и JIT-компиляцией перед началом выполнения. И синтаксис чтоб даже не сишный, а… нет, паскаль для скриптоты слишком многословен… что-то типа Rust, Go.

Чего-то на Perl смахивает

Похоже.

Но принцип ты понял.

Опции предлагаешь как скармливать? А опциональные аргументы? Или внешние программы вызывать, через system()?

Принципы C работать не будут в командной строке. Куда пригоднее для этого был бы какой-нибудь Python (не совсем).

Если скриптовый, то может tcc

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

Да даже без JIT это была бы пушка! Строгой типизации очень не хватает для скриптов.

Если нужен интерактивный интерпретатор C, то есть, например, https://root.cern/cling/. Но как шелл он, естественно, не слишком хорош :)

Чего-то на Perl смахивает

Только хуже, так как в перле разные операторы для сторокового и численного сравнения, что позволяет избежать огромного количества граблей из-за неявного приведения типов. А еще есть объявление my, позволяющее явно увидеть область действия локальной переменной (sh тоже так умеет, ключевое слово local), а так же иметь полноценные лямбда-выражения (в sh вряд ли получится)

S-Lang же.

https://en.wikipedia.org/wiki/S-Lang

https://www.jedsoft.org/slang/

https://www.jedsoft.org/slang/slsh.html

5 звёзд, регистрант старше меня, а такую фигню спрашивает…. дайте мне другой ЛОР

Меня бы больше приколол скриптовый язык со строгой типизацией

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

что-то типа Rust, Go

Есть (странные) люди, которые go как скриптовый язык используют

бери babashka и хватит жрать всякую дрянь, короче

А что такое, ну не интересовался я этим раньше, сейчас много нового узнал.

Есть Julia. Строгая типизация, JIT.

typescript ?

HolyC, шелл операционной системы TempleOS

$peace=$1;

Это какой-то очень странный Си )

А так, да, я тут на ЛОРе украл у умных людей идею с tcc.

Шебанг #!/usr/bin/tcc -run и вперёд с песней, красота )

на Perl смахивает

Что может быть проще?

ln -s /usr/bin/perl /usr/bin/sish

И ещё https://metacpan.org/pod/Shell::Perl

https://en.wikipedia.org/wiki/Ch_(computer_programming)
https://en.wikipedia.org/wiki/CINT
https://root.cern/cling/

Шебанг #!/usr/bin/tcc -run и вперёд с песней, красота )

REPL-а там нет.

TCC.

C script supported : just add #!/usr/local/bin/tcc -run at the first line of your C source, and execute it directly from the command line.

JIT-компиляцией перед началом выполнения

Взаимоисключающие параграфы. Компиляция перед началом выполнения - это AOT. А JIT это непосредственно во время и по ходу выполнения. JIT компилирует код кусками, не компилирует то, что не используется или используется редко, трассирует часто используемое и перекомпилирует на основе статистики.

Бывает связка AOT + JIT. Но так или иначе стадия компиляции перед началом выполнения - это AOT-компиляция.

P.S. Например, всем известно, что v8 имеет на борту мощный JIT компилятор и использует его во всю. Но мало кто знает, что v8 поддерживает и AOT компиляцию. Именно так устроено кэширование скриптов, v8 кэширует уже скомпилированный инвариант кода, который потом в рантайме может дополнительно оптимизировать JIT’ом. Поэтому на самом деле хромообразные браузеры не переразбирают и неперекомпилируют js при каждом открытии сайтов.

Ровно по такому же принципу очень долго время хранилась и загружалась стандартная библиотека JS, потому как написана она тоже на js (она компилировалась при первом запуске и позднее использовалась ее aot-версия. Сейчас в v8 большая часть стандартной либы, в том числе инициализация хост-объектов (объектов js) вынесено в плюсовый код). Ровно таким же образом хранится стандартная библиотека node.js.

И использовать AOT компилцию в v8 можно самому если нужные API прокинуты в рантайм - в v8 это Snapshot API, и он доступен напрямую из пользовательского кода, например в Node.JS.

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

REPL-а там нет

Знал бы зачем read-eval-print loop нужно - может быть и расстроился бы.

Небольшое неудобство только в том, что насмерть захардкожено AFF_TYPE_C. Надо или *.c, или *.i, или без fileextension. Как запустить *.sh (например) шебангом без редактирования исходников tcc я так и не понял пока.

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

Для этого можно за пару часов освоить то, что является стандартом (bash).

Для серьезных программ - пистон и т.п. во все поля.

ЕМНИП, в TempleOS что-то такое было.

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

QuickJS сгодится? Скобочки есть.

Почитал комменты, тред достоин занесения в избранное)

ccsh уже советовали?

Он «немного» неживой правда...

И он ЕМНИП исключительно скриптовый, интерактивного режима там нет

JavaScript

Да, csh и tcsh что-то странное. Ни рыба, ни мясо. Вроде как хотели сделать Shell похожим на C, а получился тот же Bash/Shell вид сбоку.

Даже знак доллара у $var не убрали.

tcc -run же

Как запустить *.sh (например) шебангом без редактирования исходников tcc я так и не понял пока.

Чё? man execve??

Есть (странные) люди, которые go как скриптовый язык используют

А как его еще использовать? Оно же и есть компилируемая скриптота. Оксюморон, но факт.

test.c:

#!/usr/bin/tcc -run
#include <stdio.h>

int main(int argc, char **argv) {

    printf("Hello world 1!\n");
    printf("Arg: %s\n", argc>1?argv[1]:"-=-");

    return(0);
}

Можно просто назвать файл без расширения.

Чё? man execve??

Можете пояснить?

$ F1="test.c"; echo -e '#!/usr/bin/tcc -run -w\nint main() {printf("filename '$F1' yes\n");}' > $F1; chmod +x $F1; ./$F1; rm ./$F1
filename test.c yes
$ F1="test.i"; echo -e '#!/usr/bin/tcc -run -w\nint main() {printf("filename '$F1' yes\n");}' > $F1; chmod +x $F1; ./$F1; rm ./$F1
filename test.i yes
$ F1="test"; echo -e '#!/usr/bin/tcc -run -w\nint main() {printf("filename '$F1' yes\n");}' > $F1; chmod +x $F1; ./$F1; rm ./$F1
filename test yes
$ F1="test.c.sh"; echo -e '#!/usr/bin/tcc -run -w\nint main() {printf("filename '$F1' yes\n");}' > $F1; chmod +x $F1; ./$F1; rm ./$F1
./test.c.sh: error: unrecognized file type
$ F1="test.sh"; echo -e '#!/usr/bin/tcc -run -w\nint main() {printf("filename '$F1' yes\n");}' > $F1; chmod +x $F1; ./$F1; rm ./$F1
./test.sh: error: unrecognized file type

как man execve может помочь обойти вшитые ограничения tcc? Прошу пояснить. Или не чёкать.

Для серьезных программ - пистон

Оксюморон

Да нет там ограничений.

Если есть системный вызов и tcc может дёрнуть соответствующую функцию из стандартной библиотеки, то именно это он и сделает. Самый простой пример на основе кода чуть выше (скрипт находится в файле test):

#!/usr/bin/tcc -run

#include <stdio.h>
#include <unistd.h>
#include <math.h>
#include <memory.h>
#include <stdlib.h>
#include <limits.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>

int main(int argc, char **argv) {
	char hostname[1024];
	struct addrinfo hints, *info, *p;
	int gai_result;

	printf("Hello world 1!\n");
	printf("Arg: %s\n", argc>1?argv[1]:"-=-");

	printf("Calculating sample: %f\n", sqrt(4)); /* This */

	/* This shouldn't work without of https at localhost, Toxo2. */
	hostname[1023] = '\0';
	memset(&hints, 0, sizeof hints);
	hints.ai_family = AF_UNSPEC;
	hints.ai_socktype = SOCK_STREAM;
	hints.ai_flags = AI_CANONNAME;
	if((gai_result = getaddrinfo(hostname, "https", &hints, &info))!= 0) {
		fprintf(stderr, "Result: %s\n", gai_strerror(gai_result));
		exit(EXIT_FAILURE);
	}
	for(p = info; p != NULL; p = p->ai_next) {
		fprintf(stderr, "hostname is: %s\n", p->ai_canonname);
	}
	freeaddrinfo(info);

	execve("./test", NULL, NULL); /* And this */
	return(0);
}

Для скриптоты на С вполне годно. Если на машине нет сервера с поддержкой https, то работать не будет. На машине с таким сервером всё работает.

Да, сам хотел с места крикнуть tcc, но тут уже опередили, как я погляжу. =)

Задача не всецело понятна.

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

Так-то вроде разумное желание. Отправь им патч. Авось примут.

Да нет там ограничений.

Ррррррррр.... ну вам-то уж точно зазорно должно быть.

Ваш шебанг не будет работать внутри файла с расширением отличным от 'c','i',"

в шебанге указывать тип файла

Наоброт. Указывать шебанг внутри файла со свободным расширением.

Чтобы файлы *.c - это были файлы Си.
А файлы *.c.sh - это были файлы со скриптом на Си. По-моему вполне логичное желание, которое сразу первым в голову приходит. А выясняется что так нельзя.

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

Так что какой-то ключ специально под это дело я бы таки ввел

Вооооооооооооооот, о том и речь. Не помешал бы ключ «интерпретировать файл как Си-текст независимо от расширения».

Эт почему?!?

Ваш шебанг не будет работать внутри файла с расширением отличным от ‘c’,‘i’,"

Файл может быть без расширения вовсе, я же там написал прямо – (скрипт находится в файле test). Будет работать. Собственно, проверяется это легко – я не зря там вообще втупую тот же скрипт из самого себя и дёргаю вот так вот нагло – execve("./test", NULL, NULL); /* And this */.

Тут всё связано с общей семантикой решения – считается что код на С является скомпилированным в некий бинарь безо всяких расширений имён файла типа как в DOS/Windows – exe,cmd,bat или ещё что. Просто С-код, который спросто компилирован и исполняется. Не думаю что кто-то, когда создавали bash и другие оболочки, надеялся на то, что кто-то напишет такой интерпретатор С-кода, который в принципе можно будет даже не компилировать. Поэтому не используйте расширения, да и всё. =)

P.S. Теста ради добавил файл t.sh с содержимым:

#!/bin/bash
echo "hi-hi"

И стал вызывать его аналогично – execve("./t.sh", NULL, NULL);. Теперь это скриптовый tcc над нами с Вами ещё и хихикает, гад такой. =)))

Хорошо, спасибо. Вам - верю.

Что-то я подустал ) Такая простая вроде хотелка:

Чтобы файлы *.c - это были файлы Си.
А файлы *.c.sh - это были файлы со скриптом на Си.

С изподвыподвертом, так с изподвыподвертом. Сдаюсь.

Пардон, я понял свою ошибку. =)

Извините, кофе пока варится, у меня утренний тупняк. =)))

Я не обратил внимание на:

А файлы *.c.sh - это были файлы со скриптом на Си.

Можно и так. Пока не готов написать именно как надо в деталях, но общее решение это использовать binfmt_misc. При помощи этого модуля ядра можно как стандартные процессы и скрипты и бинари для отличных от хостовых архитектур гонять как нативные процессы Linux (например, введя команду ./some_arm_app сразу загружать его в QEMU и просматривать по ps -a, там будет не qemu_чёттам, а именно процесс some_arm_app).

Как настраивается такое поведение системы можно прочесть вот тут. Там есть параметр interpreter, там и надо прописать путь /usr/bin/tcc. В общем, примерно понятно как это сделать, делать сам не буду – по мне tcc и сам по себе весьма неплох для моделирования поведения какой-то программы. Понятно что по скорости будем пролетать, но в принципе, прикинуть вариант решения на С вполне годно. Собственно, для чего я его и использую. Quick & dirty solution. =)

Ну право слово – не на питоне же пейсать! Сишнику-то! =)))

P.S. Ну и да, как примеры конечно же https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot

Плюсую cling.

Но есть ещё, точнее, был http://neugierig.org/software/c-repl/. Сейчас проект не поддерживается. И тоже как шелл он не очень.

В принципе, если просто как интерпретатор С, то можно и tcc -run - использовать и код вбивать прямо в stdin. Если кусок кода короткий и писать без опечаток, то в принципе неплохо. =)

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

Бггг... =)))

То что он удумал, это «а-та-та» и «ай-яй-яй». В одном флаконе.

То что он задумал реализуется через libtcc, которая есть в наборе. Там и вся нужная генерация С-кода (хоть просто С-кода, хоть с GLSL-шейдерами). И нет нужды в долгом сексе. =)))