Lines of code that changed everything (slate.com)

    As the final abbreviation, observe that a comparison against
    '\0' is redundant, since the question is merely whether the
    expression is zero. So the function would likely be written
    as

    /* strcpy:  copy t to s; pointer version 3 */
    void strcpy(char *s, char *t)   {
       while (*s++ = *t++)
           ;
   }

   Although this may seem cryptic at first sight, the notational
   convenience is considerable, and the idiom should be mastered,
   because you will see it frequently in C programs.

  rm -rf $FOO/*

  rm -rf . /*

There are 32 control characters, and DEL. The purpose of all those characters is to carry some kind of meaning. The designers of the null-terminated string decided that the meaning of NUL will be reserved for that termination. That still leaves 31 control characters and DEL which can be stored in a string, which programmers can use for other meanings. That turns out to be plenty.

The "unreasonable effectiveness" and ubiquity of null terminated strings shows that the world is perfectly capable of getting along without NUL in the middle of a string. Basically, the intuition that we can steal NUL for string termination was right (and to some extent self-fulfilling, due to the subsequent proliferation of the convention).

The idea that all possible code points of a character set are valid characters that must be stored in a string is outdated in the age of Unicode, which contains codes which are not character code points.

Null terminated strings are now the representation of a path name every major OS that has any non-negligible installed base. The choices leading to this situation weren't made by complete idiots.

And, by the way, NUL is the ASCII character; NULL is the pointer constant in C.

Common Gateway Interface. It's a specification for how web servers can process HTTP(S) requests dynamically.

EDIT: If you are wondering what modern equivalents are, AWS Lambda[1] and Azure Functions[2] are Liskov substitutable[3] as they pertain to CGI programs. Both of these products provide benefits beyond what a "classic CGI system" could offer, of course.

0 - https://en.wikipedia.org/wiki/Common_Gateway_Interface

1 - https://docs.aws.amazon.com/lambda/latest/dg/welcome.html

2 - https://docs.microsoft.com/en-us/azure/azure-functions/funct...

3 - https://en.wikipedia.org/wiki/Liskov_substitution_principle

Back when the web was young (before 1998 or so), webpages were generally static HTML files that you dumped in a directory and the webserver served up verbatim. There was no PHP, no Rails, no Django, and certainly no Node. If you wanted to do anything dynamic - like serving up content that you, the webmaster, did not write yourself - you had to write a custom webserver. Remember, this was back when C was the most popular programming language, Java was for hardware devices, Python was for academics, and Javascript didn't exist. Not many people wanted to write their own webserver.

CGI was a specification that would allow the webserver to launch an external program - written in any language you wanted - in response to an HTTP request, send it the request data, run arbitrary code, and write the response back to the web browser. The query params and other information about the request (path, user agent, host, request method, etc.) would be passed in environment variables. POST data would be passed on STDIN. The program would write the output HTML to STDOUT, and the webserver would echo that directly back to the browser.

It was slow, it was clumsy, it was insecure, and it was magical, because you simply couldn't do simple stuff like read from a database and dynamically generate a webpage otherwise, unless you wanted to write your own webserver.

The lines that the grandparent posted would fire up a Perl script and then import the CGI module to parse all the input data (no such thing as JSON back then; if you wanted the actual query params, you got "/reply" in your $ENV['PATH'], and "id=21654788&goto=item%3Fid%3D21648568%2321654788" in your $ENV['QUERY_STRING'], and had to parse them yourself). It also enabled some warnings and error checks for Perl to avoid some of the worst security nightmares. This was even more magical, because Perl offered string parsing & construction utilities and database libraries that were much easier than C, and so you could quickly write useful websites that did stuff instead of hand-typing HTML into your editor.

The monster I be, is when on the fifth line you see:

  eval { local $/; <STDIN> };