Using C as a scripting language

General Discussions
, ,
1

Hi all,

Something that is not widely known is that one can script in C instead of compiling it.

Now, ofcourse there is a fast ‘just-in-time’ compiler step that is invisible to the programmer but you probably won’t even notice.

Nevertheless, it can be quite convenient sometimes.

All you need is the tiny C compiler (tcc) which is usually found in the standard repositories and can be installed by the packetmanager

Here is an example how to turn C code into a script:

#!/usr/bin/tcc -run

#include<stdio.h>

int main(void)
{
	fputs("hello world\n",stdout);
}

don’t forget to chmod a+x script.c

happy hacking ! :slight_smile:

6 Likes
2

Wow! Good to know!

Do you find it to be flexible and adaptive to unique situations, the way SHELL programming is?


If you’ve done much with it, can you offer examples of contexts where “scripted C” would be advantageous?

Also, as a script, are there situations you can identify where “daisy-chaining” multiple “C scripts” would be the approach to be used, rather than building the monolithic C program to begin with?

2 Likes
3

Yes, certainly.
Especially when I have to generate C code on the fly (i.e. during runtime)

I sometimes generate C code with bash (using “here document” features) and pipe the result to tcc. Or run the resulting C-code in a subshell.

Sometimes when scripting in bash, and I need an extra command that bash doesn’t provide (like a custom input sanitation filter), I script it.

I don’t have examples at hand that I can show at the moment.
But I used it in a fully-automated video ingest, edit and distribution server for national/regional TV-news broadcast stations.

I could edit, repair or replace parts of the software while the system was running.

Well, the example above is a good illustration. I am very much a proponent for modularity and late binding.

“daisy-chaining” ? Yes, especially when doing parallel(simultaneous)-processing.

Working with pthreads and IPC is a bit of a drag in C and is not modular unless you clutter it up with fork/exec or system calls (and messagepassing over filedescriptors) which can get quite a painful mess fast if one is not careful.

But combining c-scipts and bash, to parallelize execution and IPC, is easy, fast and certainly a pleasure to work with. It also keeps the amount of LOC much smaller and much easier to navigate.

Since all work is directly executable sourcecode, you can have all scripts together without having an extra /bin/ for the compiled scripts and without having to remember what you did or did not compile recently.
It makes the total workflow (and bugfixing) smooth and fast. Also, bugs are often fixed within minutes without even bringing the application down.

3 Likes
4

Very nice indeed!

It looks like I feel pedantic today. You see, scripting languages are traditionally associated with interpreters. That why, I’d like to clarify that tcc does not actually interprets C code. tcc compiles C code directly into RAM and executes it. No ELF executable created on HDD.

On the other hand, a number of ‘scripting’ environments do compile scripts into intermediate bytecode (Python), use JIT (Lua, JavaScript)… Now there is the question: what is the difference? I’d like to suggest that scripting environments absolutely have their executable core programs which in their turn run scripts whether compiled or interpreted.

Hence @tkn is correct: tcc can be called a scripting environment for C language.

P.S. I have never used it myself, but they say that ‘C shell’, i.e. csh (and tcsh nowadays) has an objective to provide command language that is stylistically consistent with C.

5 Likes
5

Csh had a reasonable “reading” syntax and it was the first shell I saw with command recall; other than that it was terrible and it was difficult, if not impossible to write “scripts” with it. Tcsh was nicer, but shared the same problem.

Ksh was the first Sh-based shell with some command recall features but Bash passed it up a long time ago.

Regarding the “compilation” of scripts into various executable formats, the purpose is to speed them up somewhat because any iterative script is considerably slower in execution speed than compiled code.
Each of the intermediate code execution methods are different; they are inferior to any compiled language in speed, but quite useful and efficient for intermediate script environments that provide a user interface.

These days a LOT of user interfaces are written in Python, LUA, or Javascript; these are still “interpretive” languages but by including executable script code they are quite a bit faster than a shell without any intermediate executable code. It’s a worthwhile feature for anything that runs more than 10-20 lines of code. For instance by .bashrc file often has around 200 lines, though not all of them are executed, some are comments or whitespace; still a Bash bytecode tool would speed that up quite a bit!

4 Likes