Procesando la documentación de Laravel 4 para mejor lectura o impresión

Introducción

Aún no me acostumbro a leer textos largos desde un PDF en el computador, en especial libros y manuales me gusta tenerlos impresos para resaltarlos y hacer anotaciones en ellos.  Por este motivo hice este script muy sencillo en PHP que obtiene las secciones del sitio web de la documentación de Laravel 4 y las une en un único documento que puede ser impreso o leído con mayor facilidad.

Documentación de Laravel 4

Requisitos

El único requisito para ejecutar el script es contar con el paquete de la interfaz de línea de comando de PHP (php-cli) instalado.

Ejecución

$ php laravel4.php

Al final la ejecución se encontrará el archivo output.html en el mismo directorio con la documentación generada.

Personalización

Si desea seleccionar cuales secciones de la documentación son finalmente incluidas durante la generación del documento, modifique la variable $urls (inicialmente comentada) definiendo en ella los URL de las respectivas secciones.  En caso de no definirse (por defecto) se tomarán automáticamente las secciones encontradas en la página en linea de la documentación.

También es posible modificar la presentación del documento resultante.  Para esto ajuste como se considere las clases CSS definidas en la plantilla en la función prepareTemplate.

Licenciamiento

Este script se distribuye bajo la licencia MIT.

Versiones

Recursos

Mostrar en pantalla los errores producidos en PHP con Apache bajo Ubuntu

Introducción

Mientras que en producción mostrar al usuario final la información relacionada con el error producido es un riesgo de seguridad demasiado alto, durante el desarrollo del software es una condición necesaria para entender que está pasando con el código que se está probando.

En la mayoría de despliegues de Apache/PHP vienen ahora con esta opción desactivada, redireccionando por defecto los mensajes de error al archivo de registro habitualmente ubicado en /var/log/apache2/error.log.

Procedimiento

Es posible activar la opción de mostrar los errores de PHP en pantalla a tres diferentes niveles de acuerdo con el alcance que se le desee dar a este comportamiento.

A nivel global, esta modificación aplica a todo el servidor o sitios web publicados bajo esa configuración.

$ sudo vi /etc/php5/apache2/php.ini

error_reporting = E_ALL
display_errors = On

A nivel de un directorio o una aplicación, esta modificación afecta a los scripts ubicados bajo un directorio específico.

$ vi /var/html/un/directorio/especifico/.htaccess

<IfModule mod_php5.c>
    php_value error_reporting E_ALL

    php_value display_errors on
</IfModule>

A nivel de una sección de código específico, esta modificación afecta sólo una parte de un script.

$ vi /var/html/un/script.php

error_reporting(E_ALL);
ini_set(‘display_errors’,’On’);

Aclaración adicional

Para que los ajustes de configuración de los últimos dos niveles sean tenidos en cuenta, el directorio donde del sitio web publicado deberá tener por lo menos activa la siguiente opción.

AllowOverride Options

Esta se deberá modificar bajo /etc/apache2/mods-enabled/userdir.conf para los sitios personales de los usuarios (public_html) o /etc/apache2/sites-enabled/* para los virtualhosts existentes.

Problemas cargando sqlite.so en 20090626+lfs/sqlite.so

Introducción

Instalando Apache+PHP+MySQL en mi equipo con GNU/Linux Mint 12 encuentro el siguiente problema después de instalar el soporte para SQLite (php5-sqlite).

PHP Warning:  PHP Startup: Unable to load dynamic library ‘/usr/lib/php5/20090626+lfs/sqlite.so’ – /usr/lib/php5/20090626+lfs/sqlite.so: cannot open shared object file: No such file or directory in Unknown on line 0

La situación

Aparentemente el uso de SQLite versión 2 ha sido desestimado en pos del uso exclusivo de la versión 3, sin embargo extrañamente la configuración por defecto de PHP sigue intentando cargar su librería.

La solución

Remover la configuración de SQLite2 de PHP y utilizar la versión 3 únicamente.

$ sudo mv /etc/php5/conf.d/sqlite.ini /etc/php5/conf.d/sqlite.ini.old

Una vez evitado que este archivo de configuración sea tenido en cuenta el funcionamiento de PHP vuelve a la normalidad.

$ php -v

PHP 5.3.6-13ubuntu3.3 with Suhosin-Patch (cli) (built: Dec 13 2011 18:37:10)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

Enlaces

Convirtiendo la documentación de FuelPHP a un único documento

Introducción.

FuelPHP es un framework para el desarrollo de aplicaciones que a pesar de su muy reciente aparición es muy interesante y prometedor para el entorno del desarrollo de aplicaciones web con software libre.  Este framework es similar a Codeigniter o Kohana en términos de su simplicidad, sin embargo no se basa directamente en ninguno de ellos sino que por el contario, toma los conceptos e ideas de diseño exitosas de los principales frameworks y los integra en una única base para la implementación de aplicaciones web.

Teniendo una relativa corta edad, su desarrollo ha sido veloz y su versión 1.0 se encuentra muy próxima a publicarse.  La documentación también ha evolucionado rápidamente y se encuentra en contínua actualización.  Esta se presenta por secciones que se pueden revisar directamente siendo esto muy apropiado para las consultas rápidas de la misma sin embargo -en mi opinión personal- no es tan útil cuando se está aprendiendo del framework por primera vez ya que no es posible realizar una revisión o búsqueda líneal de los temas ni mucho menos imprimirlos.

Dado lo prometedor del framework decidí tomarme un par de minutos para desarrollar una solución que me permitiera consolidar fácilmente la documentación en un único documento para poder imprimirlo y estudiar de él.  Terminé con una pequeña herramienta basada en Javascript con jQuery que realizar esta tarea.  Debido a las limitaciones de seguridad impuestas por los navegadores es necesario que se descargue en un servidor web local la documentación para que pueda ser procesada por esta herramienta.

Debe tenerse en cuenta que los documentos generados o impresos no recibirán las contínuas actualizaciones que si recibe la versión en línea, por este motivo prefiero no distribuír el documento completo con la versión del día sino compartir el método para que pueda ser creado frecuentemente.

Instalación.

Crear una carpeta en el árbol de directorios (DOCUMENT_ROOT) públicos del servidor de páginas.

Descomprimir la distribución de la herramienta en el directorio web.

Descargar la distribución actual de FuelPHP y descomprimirla en el directorio web al mismo nivel de la herramienta. 

Los archivos contenidos en la carpeta de mas alto nivel serán similares a los mostrados a continuación en la cual se utilizó la versión 1.0-RC3 del framework.

Contenidos de la carpeta web
Contenidos de la carpeta web

 

Configuración.

El único paso necesario para configurar la herramienta consiste en editar el archivo FuelPHPOneDoc/FuelPHPOneDoc.js y modificar apropiadamente el valor de la variable baseUrl la cual deberá contener la dirección absoluta en la cual se publicó localmente la documentación de FuelPHP.  De esta manera en el ejemplo anterior, si la carpeta pública web corresponde con la dirección http://localhost/onedoc/ entonces el valor de baseUrl será http://localhost/onedoc/v1.0-rc3/docs/.

Ejecución.

Acceder al URL de la herramienta utilizando un navegador web.  En el caso del ejemplo anterior sería a la dirección http://localhost/onedoc/FuelPHPOneDoc/FuelPHPOneDoc.html.

Documentación de FuelPHP en un unico documento
Documentación de FuelPHP en un unico documento

 

Requerimiento: servidor de páginas web.

Por la razón que se mencionó anteriormente, es necesario contar con un servidor de páginas web para publicar tanto el contenido de la documentación original de FuelPHP como la herramienta para modificar su presentación.

En caso de no contarse con un servidor de páginas instalado, este podrá obtenerse de diferentes maneras: Apache (todas las plataformas), Internet Information Service (sólo Windows), XAMPP (todas las plataformas) y nginx (todas las plataformas) entre muchos otros.

Si no se cuenta con ninguno de estos servidores de páginas web pero se cuenta con soporte para el lenguaje Python, es posible utilizar temporalmente el servidor web de desarrollo que incluye este lenguaje.  Para utilizarlo será necesario abrir una terminal y ubicarse en el directorio que se convertirá en público a través de web e invocar la aplicación.

$ cd /home/jimezam/tmp/FuelPHP

Si cuenta con soporte para Python 2.x:

$ python -m SimpleHTTPServer

En cambio, si se cuenta con soporte para Python 3.x, la instrucción a ejecutar será la siguiente.

$ python -m http.server 8000

En ambos casos el puerto que se utilizará para lanzar el nuevo servidor web será el 8000 así que este tendrá que ser tenido en cuenta durante la determinación del respectivo URL.  En este caso, el URL que deberá ser consultado será http://localhost:8000/FuelPHPOneDoc/FuelPHPOneDoc.html.

Evitando el reemplazo de los guiones y comillas dobles en WordPress

Introducción.

WordPress tiene una característica que consiste en reemplazar ciertos carácteres o cadenas en sus correspondencias mas bonitas, por ejemplo reemplaza los guiones dobles por un único guión mas largo que el normal.  Esto lo hace para embellecer los textos que se publican.

Este loable objetivo puede ser interesante en la mayoría de los casos pero es un total infortunio para quienes publicamos código fuente o textos para ejecutarse en la línea de comando los cuales deberán transcribirse de manera fiel o simplemente fallarán debido a que cualquier variación como las propuestas les harán perder su validez sintáctica.

Hace un tiempo encontré como solución modificar las líneas exactas en las cuales WordPress realiza esta inoportuna conversión, sin embargo estas líneas pertenecen a un archivo del núcleo de WordPress y desafortunadamente es sobreescrito durante las actualizaciones de WordPress y por ende las modificaciones se pierden con la misma regularidad.

Para solventar esto he encontrado una solución similar que se basa en la adaptación de un plugin ya existente, así que las modificaciones perdurarán a las actualizaciones de WordPress y sólo deberán repetirse ante una posible actualización del plugin, las cuales por supuesto suceden con una frecuencia mucho menor.

Procedimiento.

Instalar y activar el plugin de WordPress llamado untexturize.

Editar el contenido del archivo wpuntexturize.php.  Por facilidad se recomienda utilizar el mismo editor de Plugins que provee WordPress.

Identificar el código fuente de la función c2c_wpuntexturize y modificar su contenido de la siguiente manera.

$char_codes = array( '&#8216;', '&#8217;', '&#8220;', '&#8221;', '&#8242;', '&#8243;',
                     '&#8212;', ' &#8212; ', '&#8211;', ' &#8211; ', 'xn--');   // nuevo.
$replacements = array( "'", "'", '"', '"', "'", '"',
                       '---', ' -- ', '--', ' - ', 'xn&#8211;');    // nuevo.
return str_replace( $char_codes, $replacements, $text );

Si se nota, las líneas marcadas con el comentario nuevo han sido agregadas con respecto al código fuente original del plugin, estas líneas corresponden con la información de los reemplazos de los guíones facultando al plugin a regresarlos a su presentación original mas allá de sólo las comillas dobles las cuales son la funcionalidad propia del complemento.

A partir del momento en que se realicen estas modificaciones, las entradas del blog mostrarán correctamente las comillas y guíones dobles en sus textos.

Enlaces.

Aplicación para el 6CCC: nuevo estilo para la programación

Introducción.

Esta es una aplicación muy sencilla que se desarrolló en PHP para el sexto Congreso Colombiano de Computación.  Todo comenzó cuando no me resultó cómoda la manera como el sitio web desplegaba la programación del evento: por bloques de auditorios siendo las filas conferencias y las columnas los días de las mismas.

Programación del 6CCC (versión original)
Programación del 6CCC (versión original)

Este estilo de presentación no es conveniente ya que no me permite visualizar fácilmente que conferencias se están realizando en un momento dado para poder decidir a cual de ellas asisto, es decir, el estilo idóneo de presentación de las conferencias debería ser en el que cada bloque representa un día del evento, cada fila un rango de tiempo específico y cada columna un auditorio donde se estén realizando las conferencias.  De esta manera, una vez ubicado el rango de tiempo que se desea consultar sólo será necesario revisar las columnas para determinar las conferencias a las que se puede asistir.

Ya que manipular manualmente esta información  para poder determinar cuales eran las conferencias que quería ver era demasiado engorroso decidi implementar una solución computacional muy simple.  Inicialmente la iba a desarrollar en Javascript por completo manipulando el árbol DOM pero me dí cuenta que podría serle de utilidad a otras personas también y preferí no sobrecargar al navegador del cliente con las operaciones de transformación del contenido del programa.  El resultado final fue el siguiente.

 

Programación del 6CCC (versión mejorada)
Programación del 6CCC (versión mejorada)

El prototipo.

Las premisas eran las siguientes.

  • No sobrecargar al cliente con cálculos en Javascript para facilitar la consulta desde móviles.
  • No requerir que se ingrese la información de la programación nuevamente, se debería tomar de la programación existente directamente.
  • Actualizarse automáticamente a la par de la programación original (esta última debería respetar su estructura HTML).
  • Facilitar la lectura de la información.
  • Facilitar la consulta de las conferencias presentándose en un momento específico del día y cuales se están presentando en este mismo momento.
  • Permitir la personalización de la presentación (esto se obtuvo mediante la implementación de una vista independiente de la lógica de procesamiento y de clases CSS).

El prototipo se implementó en PHP sin ningún tipo de framework especializado y utilizando la técnica de web scraping para obtener directamente la información de la página web original de la programación, de ahí que fuera necesario que esta respetara su estructura HTML durante las actualizaciones.  Para esto se utilizó la librería phpQuery la cual permite entre otras cosas obtener secciones de código HTML mediante rutas de selectores CSS de manera similar a jQuery.

Conclusiones.

  • El uso de phpQuery para las necesidades del prototipo no fue tan simple ni intuitivo como lo es el uso de jQuery, sin embargo una vez entendida su implementación, permitió desarrollar la funcionalidad necesaria.
  • La programación original contaba con múltiples inconsistencias: diferentes formatos de fecha, la presencia de un día adicional en la programación general, la presencia de las temáticas generales de los bloques de conferencias en el mismo contenido de las conferencias, conferencias sin hora específica y, filas y columnas vacías para generar espacios en las tablas.  Por este motivo el prototipo incluye varias validaciones para solventar estos problemas que dificultan la adquisición de la información.
  • El prototipo toma la fecha y hora del sistema para determinar las conferencias que se están presentando actualmente (tanto para resaltarlas en el listado como para mostrarlas al inicio de la programación).  No se tuvieron en cuenta diferencias en la zona horaria.
  • El prototipo no pudo ser incluído en el sitio web del congreso ya que fue desarrollado utilizando PHP 5.3 (utiliza una función anónima en PHP) mientras que el hosting utilizado por la página era 5.2 y no se contaba con la información necesaria para convertir la sintáxis de la función anónima al estilo antiguo.
  • El código fuente del prototipo fue liberado bajo la licencia Creative Commons Attribution 3.0.

Enlaces.

Give Me a Tweet, versión 1.0

Introducción.

Preparé el prototipo de esta aplicación web muy simple para experimentar con algunas librerías que tenía por revisar, que a pesar de ser muy sencillas de utilizar es bueno ir conociendo para determinar mas adelante cual de todas las disponibles es la idónea.

Esta es de manera resumida la funcionalidad del prototipo.

  • Obtiene cierta cantidad de tweets de ciertos usuarios predefinidos.
  • Los tweets son alamcenados en caché por una cantidad específica de tiempo.
  • El acceso a la página no requiere de ningún tipo de autenticación por parte del usuario.
  • Cuando el usuario accede al sitio web, el sistema elige un tweet azar y lo muestra.
  • La elección del tweet se realiza sobre los almacenados en el caché.  Si no hay caché o este es demasiado viejo, entonces se renueva automáticamente.
  • Los mensajes que no se encuentran escritos en español son traducidos automáticamente a este idioma.
  • Se prepara un enlace corto a la información del tweet.
  • Se presenta un QRCode con el enlace corto al tweet para ser fácilmente consultado por dispositivos móviles.

Herramientas.

Estas fueron las herramientas utilizadas durante el desarrollo del prototipo.

  1. Netbeans (IDE).
  2. SQLite (persistencia del caché).
  3. Blueprint CSS Framework (framework para la presentación).
  4. PHP (lenguaje de programación).
  5. Yii PHP Framework (framework de desarrollo web).
  6. Extensión de CURL para Yii (acceder al servicio REST fácilmente).
  7. API REST de Twitter (obtener los mensajes).
  8. Google Translate Service (servicio de traducción de textos).
  9. jquery-qrcode para la generación de los códigos QR.
  10. jquery-urlshortener que utiliza el servicio de bit.ly (acortador de URLs).

Prototipo.

 

Prototipo de Give Me a Tweet
Prototipo de Give Me a Tweet

Instalación.

El código fuente del protitpo puede obtenerse desde la siguiente ubicación.

https://github.com/jimezam/Give-Me-a-Tweet/tree/v1.0

Para la ejecución de la aplicación web se requiere que se cuente además de la infraestructura web, con PHP con soporte para SQLite y CURL, y la distribución del Yii PHP Framework (1.1.7 o similar) en una ubicación conocida.

Finalmente se deberán modificar los siguientes archivos para ajustarlos a la infraestructura local.

index.php:

$yii=dirname(__FILE__).’/../../yii-1.1.7.r3135/framework/yii.php’;
$config=dirname(__FILE__).’/protected/config/main.php’;

Ajustar estas rutas a la ubicación real del framework.

protected/views/tweet/show.php:

$.shortenUrl.settings.login  = ‘USUARIO‘;
$.shortenUrl.settings.apiKey = ‘LLAVE DEL API‘;

Modificar estos valores para que correspondan con la información del propietario del servicio.  Esta información se puede obtener de manera gratuita en el sitio web de bit.ly para desarrolladores.

Enlaces.

Manejar los errores fatales en PHP

Introducción.

Los errores fatales son problemas críticos de los cuales no es posible recuperar la ejecución del programa, por esta misma razón no pueden ser manejados como excepciones con bloques try/catch.

A pesar de que no es posible recuperar un programa después de un error fatal, si es posible realizar ciertas acciones de cierre que pueden ser útiles para mostrar un mensaje de error mas amigable y realizar el registro del error para su futura revisión, evitando que el lenguaje o el framework que se esté utilizando muestre un error difícil de comprender para el usuario final.

Ejemplo.

Un caso de error fatal es el producido por la recursión infinita.

function f($i)
{
 return f($i+1);
}

f(1);

El código anterior generará el siguiente mensaje de error de PHP.

Fatal error: Maximum function nesting level of '100' reached, aborting! in php shell code on line 3

Call Stack:
 12.0763      62388   1. {main}() php shell code:0
 12.0764      62548   2. f() php shell code:1
 12.0904      62772   3. f() php shell code:3
 12.0905      62996   4. f() php shell code:3
 12.0905      63220   5. f() php shell code:3
 12.0905      63444   6. f() php shell code:3
 12.0905      63668   7. f() php shell code:3
 ...

Implementación del manejo.

Desactivar la funcionalidad de PHP para mostrar los errores al usuario.

ini_set('display_errors', 0);

Registrar la función que se va a ejecutar durante el cierre de la ejecución de la aplicación.

register_shutdown_function('shutdown');

Realizar la implementación de la función de cierre.  En ella se filtran los diferentes tipos de error y se implementan, en este caso, únicamente los errores fatales.

function shutdown()
{
 if(!is_null($e = error_get_last()))
 {
  if($e['type'] == E_ERROR)
  {
    // ... implementación ...
  }
 }
}

Enlaces.

Degradar PHP 5.3 a 5.2 en GNU/Linux Ubuntu 10.10

Para degradar PHP 5.3 a la versión 5.2 en GNU/Linux Ubuntu 10.10 se debe realizar el mismo procedimiento que se mencionó antes con la versión 10.04 del sistema operativo pero con una modificación del script utilizado.

Es necesario reemplazar el nombre de la versión Lucid Lynx de Ubuntu por la actual Maverick Meerkat en la siguiente línea.

grep ‘main restricted’ /etc/apt/sources.list|grep -v “#”| sed s/lucid/karmic/g | sudo tee /etc/apt/sources.list.d/karmic.list > /dev/null

De esta manera.

grep ‘main restricted’ /etc/apt/sources.list|grep -v “#”| sed s/maverick/karmic/g | sudo tee /etc/apt/sources.list.d/karmic.list > /dev/null

Descargue el script modificado y continúe con las instrucciones mencionadas en el artículo anterior.

Si desea instalar el módulo de Apache correspondiente ejecute el siguiente comando y no acepte la versión 5.3 para que sea instalada la anterior.

$ sudo aptitude install libapache2-mod-php5

The following NEW packages will be installed:

libapache2-mod-php5{b}

0 packages upgraded, 1 newly installed, 0 to remove and 20 not upgraded.
Need to get 0B/3,105kB of archives. After unpacking 8,704kB will be used.

The following packages have unmet dependencies:
libapache2-mod-php5: Depends: php5-common (= 5.3.3-1ubuntu9.1) but 5.2.10.dfsg.1-2ubuntu6.5 is installed and it is kept back.

The following actions will resolve these dependencies:

Keep the following packages at their current version:
1)     libapache2-mod-php5 [Not Installed]

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

Install the following packages:
1)     libapache2-mod-php5 [5.2.10.dfsg.1-2ubuntu6.5 (karmic-security, karmic-updates)]

Accept this solution? [Y/n/q/?] y

The following NEW packages will be installed:
libapache2-mod-php5

0 packages upgraded, 1 newly installed, 0 to remove and 20 not upgraded.
Need to get 2,643kB of archives. After unpacking 6,189kB will be used.
Do you want to continue? [Y/n/?] y

Instalar Nginx y PHP en GNU/Linux Ubuntu 10.04

Introducción.

Desde hace un tiempo había decidido probar otros servidores de páginas diferentes de Apache en busca de uno que consumiera menos recursos, especialmente para la etapa de desarrollo.  Después de una revisión a la oferta de servidores web y a los comentarios encontrados en los foros los mas opcionados son: Nginx, Cherokee y Lighttpd.  En esta ocasión estoy probando al primero de ellos.

Instalar los paquetes necesarios.

$ sudo aptitude install php5-cgi php5-cli php5-common php5-curl php5-gd php5-json php5-mcrypt php5-sqlite php5-mysql

$ sudo aptitude install spawn-fcgi

$ sudo aptitude install nginx

Crear un directorio para el virtualhost.

En este caso se va a utilizar el sitio web por defecto (default) y se va a ubicar en /home/www/public, los virtualhosts adicionales se crean siguiendo los mismos pasos.

$ sudo mkdir -p /home/www/public

$ sudo mkdir /home/www/logs

$ sudo chown -R www-data:www-data /home/www

Establecer la configuración del virtualhost.

$ sudo vi /etc/nginx/sites-available/default

server {
    listen       80 default;
    server_name  localhost;
    access_log   /home/www/logs/localhost.access.log;

    location / {
        root   /home/www/public;
        index  index.html index.htm;
    }

    location ~ .php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /home/www/public/$fastcgi_script_name;
        include fastcgi_params;
    }
}

Tenga en cuenta que las rutas asignadas a las variables access_log, root y fastcgi_param se relacionan con los directorios creados en el paso anterior.

Activar el virtualhost.

En este caso se utiliza el sitio por defecto, sin embargo pueden crearse nuevos simplemente utilizando un nombre diferente para el enlace.

$ sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

Crear un recubrimiento para spawn-fcgi.

$ sudo vi /etc/init.d/php-fastcgi

#!/bin/bash
BIND=127.0.0.1:9000
USER=www-data
PHP_FCGI_CHILDREN=5 #15
PHP_FCGI_MAX_REQUESTS=1000

PHP_CGI=/usr/bin/php-cgi
PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS="- USER=$USER PATH=/usr/bin PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND"
RETVAL=0

start() {
      echo -n "Starting PHP FastCGI: "
      start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS
      RETVAL=$?
      echo "$PHP_CGI_NAME."
}
stop() {
      echo -n "Stopping PHP FastCGI: "
      killall -q -w -u $USER $PHP_CGI
      RETVAL=$?
      echo "$PHP_CGI_NAME."
}

case "$1" in
    start)
      start
  ;;
    stop)
      stop
  ;;
    restart)
      stop
      start
  ;;
    *)
      echo "Usage: php-fastcgi {start|stop|restart}"
      exit 1
  ;;
esac
exit $RETVAL

$ sudo chmod +x /etc/init.d/php-fastcgi

Iniciar manualmente los servicios.

$ sudo /etc/init.d/nginx start

$ sudo /etc/init.d/php-fastcgi start

Configurar el inicio automático de los servicios (opcional).

$ sudo update-rc.d nginx defaults

$ sudo update-rc.d php-fastcgi defaults

Probar el servicio.

$ vi /home/www/public/test.php

<?php phpinfo(); ?>

Acceder a la página web http://localhost/test.php desde el equipo local.