3. Programación de scripts

UNIX posee una shell con «potentes» lenguajes de programación. Entendamos potentes en el sentido de que permiten hacer bastantes cosas y no de que tengan unas características equiparables a un lenguaje de propósito general[1].

La shell más usada en el mundo linux es bash, aunque esto es sólo una verdad a medias. Lo es para el uso interactivo, pero en las derivadas de debian, la shell para la ejecución de script no interactivos es dash, una variante de almquist shell, que se caracteriza por ser mucho más liviana y no disponer de muchas de las características extendidas[2]. Entendamos que ambas tienen una base común (el estándar POSIX), pero que bash implementa algunas extensiones de las que carece dash, por lo que todo lo que sea escrito para dash, funciona en bash, pero no al revés.

Antes de empezar, es importante remarcar que la programación de scripts no tiene excesiva complicación desde el punto de vista de la pura programación: la programación es estrictamente estructurada, no hay muchas estructuras de control y las estructuras de datos que podemos crear son bastante escasas[3]. De hecho, programar un script no es más que automatizar una tarea que ya sabemos de antemano hacer, así que la verdadera dificultad radica en saber hacer esta tarea, es decir, en conocer suficientemente el sistema. Por ejemplo, en estos mismo apuntes, para la gestión remota de servidores, se propone un script, que utiliza la contraseña de usuario proporcionada durante la autenticación para desbloquear la clave privada de acceso a un un servidor SSH remoto: esto permite conectarse al servidor sin necesidad de introducir clave adicional alguna. La dificultad del script no está tanto en la programación, que es bastante sencilla, sino en saber que para ello es necesario manipular el proceso de autenticación en el sistema y saber cómo hacerlo. es decir, saber cómo funciona pam. Dicho de otro modo, para que la programación de scripts sea útil es imprescindible primero conocer más que superficialmente el sistema.

Advertencia

bash es una pésima elección para aprender a programar[4]. Estos apuntes supondrán que se tienen al menos unos conocimientos modestos de programación estructurada.

Descompondremos el breve curso en:

• 3.1. Conceptos básicos
  • 3.1.1. Sabores
  • 3.1.2. Características
  • 3.1.3. Línea de shebang
  • 3.1.4. Variables
  • 3.1.5. Sustituciones en línea
  • 3.1.6. Concatenación de órdenes
  • 3.1.7. Operaciones
• 3.2. Entrada/Salida
  • 3.2.1. Salida
  • 3.2.2. Entrada
  • 3.2.3. Redirecciones
  • 3.2.4. Valor de retorno
  • 3.2.5. Argumentos
• 3.3. Estructuras de control
  • 3.3.1. if
  • 3.3.2. case
  • 3.3.3. while/until
  • 3.3.4. for
  • 3.3.5. Bloque
  • 3.3.6. Bonus track: xargs
• 3.4. Datos complejos
  • 3.4.1. Arrays
  • 3.4.2. Diccionarios
  • 3.4.3. Series de datos en POSIX
• 3.5. Funciones
• 3.6. Otros aspectos
  • 3.6.1. Detección de la shell
  • 3.6.2. Tratamiento de argumentos
  • 3.6.3. Preevaluación de órdenes
  • 3.6.4. Captura de eventos
  • 3.6.5. awk en una línea
  • 3.6.6. Script molones
  • 3.6.7. Depuración
  • 3.6.8. Bitácora de sucesos
  • 3.6.9. Código de salida en tuberías
  • 3.6.10. Trucos y consejos
• 3.7. Ejercicios sobre scripts
  • 3.7.1. Ejercicios mínimos
  • 3.7.2. Ejercicios
  • 3.7.3. Ejercicios prácticos

Enlaces de interés

1. Estándar POSIX

2. Rich’s sh (POSIX shell) tricks

3. Manual de referencia de Bash

4. The Bash Hacker Wiki

5. Guía de programación avanzada con bash

6. Greg’s wiki, que, además de mucha otra información, incluye una colección de errores habituales al programar en bash la mayor parte de los cuales son extensibles a la programación en el estándar POSIX.

Notas al pie

[1]

De hecho, python se usa mucho como lenguaje de scripting entre los administradores de sistemas, cuando el código es demasiado complicado como para abordarlo con el lenguaje de la shell. También es muy socorrido perl.

[2]

Efectivamente:

# readlink -f /bin/sh
/bin/dash

[3]

Es más, si necesitamos hacer un script que maneje estructuras de datos algo complicadas, es mejor olvidarse de la shell y programarlo directamente en python, perl u otro lenguaje apropiado.

[4]

Es más, subcribimos las palabras con que Rich encabeza su recopilación de artimañas:

Creo firmemente que los lenguajes derivados de la Bourne shell son, para la programación, extremadamente malos, tanto como lo es también Perl, y estimo que programar en ellos es un sobresfuerzo absolutamente errado, si no se persigue escribir un código altamente portable entre distintas plataformas.