From Newsgroup: comp.lang.c

Recently discovered this wacky project <https://www.netfort.gr.jp/~dancer/software/binfmtc.html>, using the Linux binfmt mechanism (plus suitable shebang-style lines) to allow the direct execution of C source files, and also assembly-language source files, as though they were interpreted scripts.

Of course behind the scenes the code is actually compiled through GCC to a temporary executable, which is then launched.

HasnrCOt been updated in a very long while, but itrCOs still in the current Debian repositories ...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-09-30, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Recently discovered this wacky project
<https://www.netfort.gr.jp/~dancer/software/binfmtc.html>, using the Linux
binfmt mechanism (plus suitable shebang-style lines) to allow the direct execution of C source files, and also assembly-language source files, as though they were interpreted scripts.

Low Drop-Out didn't get the memo about Rosetta Code ten plus years ago:

https://rosettacode.org/wiki/Multiline_shebang#C

There is no need to use the Linux-specific binfmt module; it works
portably via hash bang.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Recently discovered this wacky project <https://www.netfort.gr.jp/~dancer/software/binfmtc.html>, using the Linux binfmt mechanism (plus suitable shebang-style lines) to allow the direct execution of C source files, and also assembly-language source files, as though they were interpreted scripts.

Of course behind the scenes the code is actually compiled through GCC to a temporary executable, which is then launched.

HasnrCOt been updated in a very long while, but itrCOs still in the current Debian repositories ...

For scripting gcc compile time is problematic. In such case it is better
to use tiny C which compiles much faster. Also, tiny C can compile to
memory, so there is behind the scene messing with temporary files.

OTOH I find concept of C scripting uninteresting. For me need for
compiled executable is not a problem. Main attraction of scripting
langages is due to language and implementation features. That is
usualy scripting languages do extensive checking at runtime and
offer convenience features like garbage collection, buitin functions
etc. Such features does not fit well with C and what can be added
to C works for executables too. Additionaly, with C I depend more
on compile time checking which is different than usual way to
develop scripts.

There is thing called cint (C interpreter), that probably would be
more useful for scripting (as it did substantial checks at runtime).
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 30.09.2025 13:24, Waldek Hebisch wrote:

Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Recently discovered this wacky project
<https://www.netfort.gr.jp/~dancer/software/binfmtc.html>, using the Linux >> binfmt mechanism (plus suitable shebang-style lines) to allow the direct
execution of C source files, and also assembly-language source files, as
though they were interpreted scripts.

Of course behind the scenes the code is actually compiled through GCC to a >> temporary executable, which is then launched.

HasnrCOt been updated in a very long while, but itrCOs still in the current >> Debian repositories ...

For scripting gcc compile time is problematic. In such case it is better
to use tiny C which compiles much faster. Also, tiny C can compile to memory, so there is behind the scene messing with temporary files.

OTOH I find concept of C scripting uninteresting. For me need for
compiled executable is not a problem. Main attraction of scripting
langages is due to language and implementation features.

In scripting I typically also want to not bother with some language
properties of compiled languages (like declarations, initializations, #includes, a compile time or complex a runtime environment, etc.). I
want to have small programs without ballast where I can also develop prototypes, simple tasks, and also larger programs quickly.

That is
usualy scripting languages do extensive checking at runtime and
offer convenience features like garbage collection, buitin functions
etc.

Yes. But it would [for me] not be a hindrance to have checks before
the program gets executed, if the checks are simple and fast (have a
linear complexity in the static size of the program text), to obtain
a more reliability program.

Such features does not fit well with C and what can be added
to C works for executables too. Additionaly, with C I depend more
on compile time checking which is different than usual way to
develop scripts.

There is thing called cint (C interpreter), that probably would be
more useful for scripting (as it did substantial checks at runtime).

I don't think so, *if* it requires all the usual "C" stuff mentioned
above. (YMMV, of course.)

BTW; in another newsgroup there's a poster who said he uses another
high level language for scripting, one that is also supported by an interpreter. IMO the interpretation of a language is not the primary
(or dedicated) property that makes a language useful for scripting.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2