Una de las cosas arcanas de la Web para mí fue el concepto de CGI. ¿Un lenguaje de programación? ¿Un protocolo? ¿Se come?
Con la llegada de PHP y su instauración de módulo por defecto en todo servidor web que se precie, el uso del CGI como tal se ha ido despreciando, pero siempre me quedó la duda: ¿cómo funciona?
Bueno, hoy resolví (por lo menos en parte) el misterio.
CGI es un estándar que detalla como el servidor interactúa con otros programas dentro del mismo computador. Por ejemplo, se le puede decir al servidor (Apache, por favor) que todos los programas que estén en un determinado directorio son scripts o programas a ser ejecutados. También, si se quiere, se puede hacer que uno de estos programas se encargue de ejecutar otros archivos de una determinada extensión.
Ejemplifiquemos. Tenemos un lindo servidor apache que sirve página en /var/http/localhost. La primera opción nos dice que se pueden ejecutar programas directamente a través de un directorio específico. Entonces, en /var/http/localhost/scripts-ruby/ ponemos varios scripts en ruby y le decimos a Apache, con la instrucción

ScriptAlias /cgi-ruby/ "/var/http/localhost/scripts-ruby/"

que llameremos a los script con URL con la base

http://servidor/cgi-ruby

. Entonces, si tenemos dos scripts llamados script1.rb y script2.rb, bastará con hacer

http://servidor/cgi-ruby/script1.rb
http://servidor/cgi-ruby/script2.rb

El servidor los ejecutará tal cual como si lo hicieramos desde la línea de comandos, ya que si es un script leerá la primera línea para ver cual es el ejecutable responsable.
La segunda forma, es tener un programa que se encargue de procesar el archivo al cual se quiere acceder, donde quiera que estos estén; actualmente, es el método por defecto que se ocupa con php. Se le dice al servidor que ocupe el ejecutable 'php' para que procese todos los archivos terminados en .php. También podría darse el caso que se le pidiese a un programa que generase imágenes en base a una descripción en un archivo de texto.
Para nuestro ejemplo, trataremos de crear un CGI para ruby

Action ruby-script /cgi-ruby/ruby-cgi.sh
AddHandler ruby-script .rb

Action señala que crearemos un 'modo de ejecución' llamado ruby-script, del cual será encargado el archivo que se encuentra, en la URL, en /cgi-ruby/ruby-cgi.sh
lo que traducido en la ruta real es /var/http/localhost/scripts-ruby/ruby-cgi.sh.
Con AddHandler, instruimos a nuestro obediente Apache que todos los archivos terminado en .rb deben ser procesados por el ejecutable encargado de la acción 'ruby-script', lo cual ya definimos.

Cómo funciona CGI

Ahora viene la pregunta del millón: ¿cómo /(·$&·/· · se pasa la información desde el servidor al ejecutable? La respuesta es mucho más sencilla de lo que creía: por variables de entorno La especificación está en http://hoohoo.ncsa.uiuc.edu/cgi/env.html. Para los que se saben de memoria la salida de phpinfo(), no será ninguna sorpresa, ya que son las variables de $_SERVER .
Los campos enviados por GET van en la variable QUERY_STRING y lo enviado por POST debe ser leído desde la entrada estándar (standard input). Simple, no?
Ahora bien, estábamos con nuestro script que hacía de 'CGI'. La forma más sencilla de hacer que haga como puente es

#/bin/bash
# ruby-cgi.sh
# Permite ser usado como action para Apache
ruby -- "$PATH_TRANSLATED" "@"

Nada más. La variable de entorno PATH_TRANSLATED nos dice la ruta real del script, y le envíamos los argumentos que pueden ser enviados, lo cual se da en ocasiones muy particulares.
Antes de terminar, todo CGI debe enviar antes de cualquier contenido una cabecera, que usualmente indica el status de la consulta (200 si está todo OK, 404 si no existe la página, etc) y el tipo de contenido, tras lo cual se agrega una línea en blanco. Por ejemplo, una salida CGI podría ser

Status: 200
Content-type: text/html

Esto es CGI!

Ahora sí que sí. Después de todo este enredo, uno se da cuenta lo simpático que es PHP, que oculta todo esto a nuestros ojos :) Pero en casos de emergencia, podemos tirar hasta un programa bash para que ejecute una tarea por nosotros. Tienen que tener cuidado, eso sí, con la seguridad.