Sync’ up! … without getting drained

jan 6


For some reason, I got it in my head that ‘CGI’ scripts were exclusively for Perl (and maybe Python). That’s how I remembered it from the ’90s, and since I got into PHP around that time, that’s just how I conceived everything over in ‘cgi-bin’ land.

And I am hardly to blame! Why just today, I was looking over my friend’s shoulder as she was going through a CSS3 book, and there in the introduction it was again. In a list of languages as they pertain to web frameworks was Ruby as to Rails, Python as to Django, and Perl as to CGI.

Decades have gone by, and I have been knee deep in the web for all it. From the beginning, I’ve been there. So, you can imagine how upset I got when I discovered that ‘cgi-bin’ is just a namespace (a directory in your root that your web server is exposing), and anything in there that is ‘755’ and ‘printf’ at least the following is bona fide CGI goodness:

printf "Content-type: application/json\n\n"

So long as your server is configured to serve ‘cgi-bin’ scripts, then this is the jumping off place to have Erlang escripts serving dynamic content; C, OCaml, Rust, Csh, you name it. (Yes, and Perl of course.)

The misnomer for me was ‘cgi scripts’ where I thought that a scripting language (and possibly only Perl, as I knew that was indeed a scripting language) was required for CGI. Man was I ever mistaken.

I guess it’s better late than never, but I’m bummed that for so long, I could have been creating lightweight web-apps, and never needing to reach for tools like RoR, Cowboy (Erlang), etc. I could have just opened up my console, went to town on a shell script, and made powerful, dynamic web-apps then and there.

I’m sure this is common knowledge for most, but if it’s news, let this shake you by the shoulders that the ol’ CGI, or its cousin, ‘fastcgi,’ are there for those language agnostics out there.