A continuación algunos tips a utilizar durante la creación de scripts en bash.
Cabecera
#!/bin/bash
#-------------------------------------------------------------------------------
# SPDX-License-Identifier: GPL-3.0-or-later
# SPDX-FileCopyrightText: 2021, Juan Picca <juan.picca@jumapico.uy>
#
# Script documentation
#
#-------------------------------------------------------------------------------
[ -n "$DEBUG" ] && { export PS4='+ [${BASH_SOURCE##*/}:${LINENO}] '; set -x; }
set -euo pipefail
Esta consta de:
-
Licencia.
Si un archivo no indica licencia (y tampoco el proyecto que lo contiene) se debe suponer que este archivo es privado y no puede utilizarse.
Para especificar la licencia, evitar tener que incluir el texto de la licencia y para que sea fácilmente escaneable por un programa (machine-readable) es que se utilizan los identificadores de licencia sugeridos por el proyecto spdx, el cual también indica la forma de comentar la licencia de un archivo, utilizando el string
SPDX-License-Identifier:dentro de un comentario, seguido de la licencia elegida.Sobre el porqué de utilizar la licencia GPL, me remito a un post de Drew DeVault, https://drewdevault.com/2019/06/13/My-journey-from-MIT-to-GPL.html, ya que coincido con la idea de que es bueno exigir a quien se beneficia del esfuerzo de uno que también sea capaz de esforzarse por los demás.
-
Autor.
Quizás por falta de modestia, por deseo de atribución de obra o simplemente por responsabilidad ante el trabajo realizado, considero que hay que reconocer al autor de un trabajo. Nuevamente, el proyecto spdx utiliza el string
SPDX-FileCopyrightTextpara indicar el año o período de realización del trabajo y Nombre y/o email del autor. -
Documentación del script.
Luego de la licencia y el autor, imprescindible indicar el motivo del script, que problema se busca resolver o alguna aclaración de uso. Sobre el contenido, cualquier indicación es mejor que ninguna y sobre el formato preferiblemente simplemente texto.
-
Decoración del encabezado.
Para diferenciar claramente el encabezado del script, y aunque parezca de hace 20 años, se completa la linea a la columna 80 con el carácter
-. Se utilizan 80 carácteres por linea ya que es el límite al que me he acostumbrado naturalmente, aparte de ser una buena práctica y la facilidad de lectura que tiene. Ni que mencionar que no soy el único que piensa lo anterior. -
Opciones de traza de ejecución del script.
La linea
[ -n "$DEBUG" ] && { export PS4='+ [${BASH_SOURCE##*/}:${LINENO}] '; set -x; }habilita la impresión del comando que va a ser ejecutado en bash si se define la variable
DEBUG(sin importar su valor).Lo anterior es mucho más comodo que estar ejecutando el script utilizando
/bin/bash -x script. El truco de cambio del promptPS4lo tomé de plenv.Otros tips de debugging se puede encontrar en el sitio bash-hackers.
-
Opciones para detección de errores.
Para aumentar la detección temprana de errores durante la escritura y depuración de los scripts se utiliza
set -euo pipefailLas ventajas del setting anterior se pueden encontrar en distintos posts como el titulado Safer bash scripts with ‘set -euxo pipefail’.
Herramientas
-
Hasta donde se no hay otro linter que se le compare así que no habría mucho para elegir, pero shellcheck está catalogado como una muy buena herramienta.
Vale la pena mencionar que por completitud se deberían agregar
- Testing framework
- Formateador de código
pero ya que no utilizo ninguna de los dos herramientas anteriores no conozco cual podría recomendarse.