Why CGI-BIN scripts are an attractive thing for many people
The recent Bash vulnerability has people suddenly talking about CGI-BIN scripts, among other things, and so the following Twitter exchange took place:
@dreid: Don't use CGI scripts. For reals.
@thatcks: My lightweight and simple deployment options are CGI scripts or PHP code. I'll take CGI scripts as the lesser evil.
@eevee: i am pretty interested in solving this problem. what are your constraints
This really deserves more of a reply than I could give on Twitter, so here's my attempt at explaining the enduring attraction of CGI scripts.
In a nutshell, the practical attraction of CGI is that it starts
really simple and then you can make things more elaborate if you
need it. Once the web server supports it in general, the minimal
CGI script deployment is a single executable file written in the
language of your choice. For
GET based CGI scripts, this program
runs in a quite simple environment (call it an API if you want) for
both looking at the incoming request and dumping out its reply (life
is slightly more difficult if you're dealing with
Updating your CGI script is as simple as editing it or copying in
a new version and your update is guaranteed to take effect immediately;
deactivating your script is equally simple. If you're using at least
Apache you can easily give your CGI script a simple authentication
system (with HTTP Basic authentication).
In the category of easy deployment, Apache often allows you to
exercise a lot of control over this process without needing to
involve the web server administrator to change the global web server
.htaccess control you can do things like add
your own basic authentication, add access control, and do some
URL rewriting. This is part of how CGI scripts
allow you to make things more elaborate if you need to. In particular,
if your 'CGI script' grows big enough you don't have to stick with
a single file; depending on your language there are all sorts of
options to expand into auxiliary files and quite complicated systems
(my Rube Goldberg lashup
is an extreme case).
Out of all of the commonly available web application systems (at least on Unix), the only one that has a similar feature list and a similar ease of going from small to large is PHP. Just like CGI scripts you can start with a single PHP file that you drop somewhere and then can grow in various ways, and PHP has a simple CGI-like API (maybe even simpler, since you can conveniently intermix PHP and HTML). Everything else has a more complex deployment process (especially if you're starting from scratch) and often a more complex management process.
CGI scripts are not ideal for large applications, to say the least. But they are great for small, quick things and they have an appealingly simple deployment story for even moderate jobs like a DHCP registration system.
By the way, this is part of the reason that people write CGI scripts in (Bourne) shell. Bourne shell is itself a very concise language for relatively simple things, and if all you are doing is something relatively simple, well, there you go. A Bourne shell script is likely to be shorter and faster to write than almost anything else.
(Expert Perl programmers can probably dash off Perl scripts that are about as compact as that, but I think there are more relatively competent Bourne shell scripters among sysadmins than there are relatively expert Perl programmers.)