Pretty.c

the original definition is likely tossing shell commands in a file to run later. chaining commands together. since perl and python supplanted this, they get lumped in as 'scripting languages'. both certainly can be used to write long running systems or short one off tasks.

compiled languages are rarely used for one offs because the effort they require is usually greater than the task calls for.

a big part of perl/python use is in tying together libraries written in more difficult lower level compiled languages.

you'll also see scripting used to refer to languages embedded in larger projects. lua scripts to control entities in a game, for instance. do they compile these somehow? I never did in the little project I used lua for.

----

all of that together, I expect that scripting as a concept largely boils down to conceptually simpler languages with less view of the ugly underbelly of how things actually work in a computer, used to chain together abstractions created by lower level code.

scripting is duct-tape. whether you duct-tape together a one-off task or some wad of long running functionality is besides the point.

Uff, I’m so sorry to hear! I can see how that joke could be really not funny for someone that has gone through some crappy stuff.

I hope you stay strong as you work through such a rough life-changing diagnosis.

char* is just raw bytes.

At the language level C historically hasn't offered much support for working with specific character sets and their encodings. With C17 and C23 we get u"...", U"...", u8"...", type char8_t, and similar, but there's still little/no built-in tooling for text processing.

For text processing work with char* whose bytes are some encoding/s of Unicode, e.g. UTF-8, then you an use a C library such as libunistring or ICU.

However the bytes of a char* could instead be an encoding of a non-Unicode character set, e.g. GB2312 encoded as EUC-CN.

So char* is character set and encoding agnostic. And C-the-language doesn't even try to offer you tools for working with different sets and encodings. Instead, you can use a library or write your own code for that purpose.

A number of languages make the same decision, keeping the string type set/encoding agnostic, with libraries taking up the slack.

In Nim, for example, the string type is essentially raw bytes (string literals in .nim sources are UTF-8). If you're doing Unicode text processing then you'd use facilities from the std/unicode module

https://nim-lang.org/docs/unicode.html

Same story with Zig

https://ziglang.org/documentation/0.8.0/std/#std;unicode

Lua too, and you'll probably use a 3rd party library such as luaut8 for working with Unicode/UTF-8

https://github.com/starwing/luautf8

Returning to the matter of pretty.c, since it's just sugar for C, it makes sense (to me) that the string type is just an alias for the set/encoding agnostic char*. It's up to the programmer to know and decide what the bytes represent and choose a library accordingly.

It is, if you use clang.