El script que revisa cada parche del kernel de Linux está escrito en Perl (Parte I)

Cada vez que alguien envía un parche al kernel de Linux, antes de que ningún mantenedor le eche un vistazo humano, ese parche pasa por un script llamado checkpatch.pl, que vive en el propio árbol de código fuente, en scripts/checkpatch.pl. La documentación oficial del kernel lo describe sin rodeos: es «un script Perl que revisa violaciones triviales de estilo en los parches y, opcionalmente, las corrige». No es una reliquia olvidada en un rincón del repositorio: es la primera línea de revisión automática por la que pasan literalmente miles de contribuciones al año, en uno de los proyectos de software más escrutados del planeta.

Cuento esto porque es el tipo de dato que desmonta, sin necesidad de discutir nada, la idea de que Perl es un lenguaje muerto que solo sobrevive en sistemas heredados de los años noventa. Sigue vivo, y no de casualidad: está exactamente donde siempre ha sido mejor que casi cualquier alternativa, en el trabajo de procesar texto rápido y sin ceremonia. Esta es la primera de dos entregas sobre Perl pensadas para quien administra sistemas Linux y nunca le ha dedicado ni media tarde: en esta vamos a entender de dónde viene, por qué sigue instalado en todas partes, y a escribir las primeras líneas; en la segunda entraremos en lo que de verdad interesa a un sysadmin—procesar logs y automatizar tareas de gestión del sistema.

De un chiste de Larry Wall a la fontanería de Unix

Perl nació el 18 de diciembre de 1987, cuando su creador, Larry Wall, lo anunció como una herramienta pensada para tareas de procesamiento de texto que sed y awk resolvían a medias. Wall, que venía del mundo de la lingüística antes que de la informática pura, resumió su filosofía de diseño con una frase que sigue citándose treinta y ocho años después: «las cosas fáciles deberían ser fáciles, y las difíciles deberían ser posibles» («easy things should be easy and hard things should be possible»). Es una declaración de intenciones que explica bastante bien por qué Perl tiene fama de lenguaje permisivo hasta el extremo —hay más de una forma de hacer lo mismo, y el propio lenguaje no te va a obligar a elegir la más elegante—.

Ese pragmatismo casi sucio es precisamente lo que lo hizo indispensable en el ecosistema Unix de finales de los ochenta y los noventa. dpkg, el gestor de paquetes que todavía hoy sostiene por debajo a Debian y a toda su familia de distribuciones (Ubuntu incluida), se escribió originalmente en shell script en 1994 por Ian Murdock, y muy pronto Matt Welsh y Carl Streeter lo reescribieron en Perl, antes de que Ian Jackson volviera a reescribir el núcleo en C ese mismo año. El dato interesante es que ese paso por Perl no fue un episodio cerrado: Debian sigue distribuyendo hoy un paquete llamado libdpkg-perl, con módulos Perl de los que todavía dependen varias de las herramientas del propio ecosistema de construcción de paquetes. Perl no fue una fase que dpkg superó; fue una capa que se quedó incrustada y que sigue ahí.

Por qué sigue instalado en tu distribución aunque nunca lo hayas tocado

Esto responde a la pregunta que probablemente te trajo hasta aquí: si Python domina hoy la conversación sobre scripting y automatización, ¿por qué sigue apareciendo Perl en el apt list --installed o el rpm -qa de cualquier distribución mínimamente completa? La respuesta corta es que buena parte del andamiaje interno de Linux —herramientas de construcción, scripts de gestión de paquetes, utilidades de administración de bajo nivel escritas hace quince o veinte años— se apoya en Perl, y reescribir todo eso en otro lenguaje no le compensa a nadie cuando funciona perfectamente bien. A eso se suma que Perl trae de serie, sin instalar ni un módulo adicional, un motor de expresiones regulares extraordinariamente potente y una forma muy directa de leer, transformar y volver a escribir texto línea a línea, que es exactamente el tipo de tarea que un script de sistema necesita resolver constantemente.

Esto no es un canto nostálgico a «todo tiempo pasado fue mejor». Si hoy tuvieras que elegir un lenguaje para automatizar tareas nuevas de sistema —levantar un servicio, hablar con una API, escribir una herramienta que use varios colaboradores en el futuro—, la recomendación honesta es Python: tiene un ecosistema de librerías mucho más vivo hoy, una sintaxis más legible para quien no lo ha usado nunca, y es lo que la inmensa mayoría de herramientas modernas de automatización (Ansible, por ejemplo) esperan que sepas. Pero sostener que Perl «ya no sirve para nada» es distinto a decir que no es la primera opción para proyectos nuevos: entender lo básico de Perl te permite leer, y si hace falta tocar, la enorme cantidad de scripts de sistema que llevan Perl en la cabecera del fichero (#!/usr/bin/perl) desde antes de que muchos sysadmins actuales empezaran en esto. Y para una tarea muy concreta —un filtrado de texto rápido, sin montar un proyecto ni una estructura de ficheros— sigue siendo, como veremos en la Parte II, extremadamente cómodo.

BASH                    PERL                         PYTHON
════                    ════                         ══════
Pegamento de            Procesamiento de texto        Lenguaje de propósito
comandos del            y automatización de           general: legible,
sistema. Ideal          sistema "de toda la           gran ecosistema de
para encadenar          vida". Regex nativas,         librerías, mejor
herramientas ya         una sola línea puede          elección para
existentes.             sustituir un pipeline         proyectos nuevos
                         de grep+sed+awk.              de cierto tamaño.

Lo mínimo para no sentirte perdido delante de un script en Perl

No hace falta instalar nada en la inmensa mayoría de distribuciones: si tienes una terminal Linux delante, casi con toda seguridad ya tienes perl disponible. Compruébalo con:

perl -v

Un script de Perl empieza, igual que uno de bash, con una línea shebang que indica el intérprete:

#!/usr/bin/perl
use strict;
use warnings;

print "Hola, sysadmin\n";

Las dos líneas use strict; y use warnings; no son decoración: obligan a declarar las variables antes de usarlas y avisan de errores sutiles (una variable mal escrita, una comparación rara) que en Perl clásico se tragaban en silencio. Cualquier script que escribas a partir de ahora debería llevarlas siempre, sin excepción —es la diferencia entre un script que falla ruidosamente cuando algo va mal y uno que falla en silencio tres semanas después, en producción, de la forma más difícil de depurar.

Perl distingue tres tipos de variables por el símbolo con el que empiezan, y esto sorprende a quien viene de bash o de Python, donde ese matiz no existe de la misma forma:

my $nombre = "servidor01";        # escalar: un único valor
my @discos = ("/", "/var", "/home"); # array: una lista de valores
my %uso = (                        # hash: pares clave-valor
    "/"     => 42,
    "/var"  => 78,
    "/home" => 15,
);

foreach my $disco (@discos) {
    print "Uso de $disco: $uso{$disco}%\n";
}

El símbolo no cambia según lo que hagas con la variable: $nombre siempre lleva $ aunque sea parte de un array o de un hash cuando accedes a un elemento suelto ($discos[0], $uso{"/var"}), mientras que @ y % se usan cuando hablas del array o del hash completo. Es una convención que al principio se siente arbitraria y que, en cuanto se interioriza, hace que el código sea más fácil de leer de un vistazo: ves el símbolo y ya sabes si estás mirando un valor suelto o una colección.

La condición y el bucle, sin sorpresas

Si ya conoces bash o cualquier otro lenguaje, las estructuras de control de Perl no van a suponerte ningún esfuerzo especial —es, de hecho, una de las cosas en las que Perl es deliberadamente poco original—:

my $carga = 3.8;

if ($carga > 3.0) {
    print "Carga alta: $carga\n";
} elsif ($carga > 1.0) {
    print "Carga moderada: $carga\n";
} else {
    print "Carga normal: $carga\n";
}

Y una variante muy propia del estilo Perl, el modificador de condición al final de la línea, que conviene conocer porque vas a encontrártelo constantemente en scripts ajenos:

print "Alerta: carga alta ($carga)\n" if $carga > 3.0;

Esa segunda forma no es un capricho estilístico: es exactamente el tipo de construcción compacta que hace que Perl siga siendo tan cómodo para los one-liners que veremos en la Parte II, donde una sola línea en la terminal puede sustituir un pipeline entero de grep, sed y awk encadenados.

Qué queda para la Parte II

Con esto ya tienes lo justo para leer un script Perl sin sentir que estás mirando jeroglíficos, y para escribir uno propio si hace falta. Pero la razón real por la que a un administrador de sistemas le compensa dedicarle una tarde a Perl no está en la sintaxis básica —eso lo tiene cualquier lenguaje—, sino en lo que pasa cuando lo apuntas contra un fichero de log de dos gigabytes o contra la salida de ps aux de un servidor con quinientos procesos. Eso, con ejemplos reales y comandos que puedes copiar y ejecutar hoy mismo, es exactamente de lo que trata la Parte II.

Serie

• Parte I (este artículo): de dónde viene Perl, por qué sigue en cualquier distribución Linux, y la sintaxis básica para no sentirte perdido.
• Parte II: Perl para el día a día del sysadmin — logs, procesos, one-liners y automatización básica del sistema.

Fuentes:

• The Linux Kernel Documentation — Checkpatch
• torvalds/linux — scripts/checkpatch.pl
• TechCrunch — print «Happy 25th Birthday, Perl»;
• Wikipedia — Dpkg (historia del proyecto)
• Debian — paquete libdpkg-perl