¿Cómo puedo fortalecer los scripts de bash para que no causen daño cuando se cambien en el futuro?

Entonces, eliminé mi carpeta de inicio (o, más precisamente, todos los archivos a los que tenía acceso de escritura). Lo que pasó es que tuve

build="build"
...
rm -rf "${build}/"*
...
<do other things with $build>

en un script bash y, después de no necesitarlo más $build, eliminar la declaración y todos sus usos, pero el rm. Bash felizmente se expande a rm -rf /*. Sí.

Me sentí estúpido, instalé la copia de seguridad, rehice el trabajo que perdí. Tratando de pasar la vergüenza.

Ahora, me pregunto: ¿cuáles son las técnicas para escribir scripts de bash para que tales errores no puedan ocurrir, o al menos sean menos probables? Por ejemplo, si hubiera escrito

FileUtils.rm_rf("#{build}/*")

En un guión de Ruby, el intérprete se habría quejado de buildno haber sido declarado, por lo que el lenguaje me protege.

Lo que he considerado en bash, además de acorralar rm(que, como mencionan muchas respuestas en preguntas relacionadas, no es nada problemático):

1. rm -rf "./${build}/"*
   Eso habría matado mi trabajo actual (un repositorio de Git) pero nada más.
2. Una variante / parametrización de rmeso requiere interacción cuando se actúa fuera del directorio actual. (No se pudo encontrar ninguno). Efecto similar.

¿Es eso, o hay otras formas de escribir scripts de bash que son "robustos" en este sentido?

set -u

o

set -o nounset

Esto haría que el shell actual trate las expansiones de variables no definidas como un error:

$ unset build
$ set -u
$ rm -rf "$build"/*
bash: build: unbound variable

set -uy set -o nounsetson opciones de shell POSIX .

Un vacío valor sería no provocar un error sin embargo.

Para eso, usa

$ rm -rf "${build:?Error, variable is empty or unset}"/*
bash: build: Error, variable is empty or unset

La expansión de ${variable:?word}se expandiría al valor de a variablemenos que esté vacía o sin establecer. Si está vacío o sin establecer, wordse mostrará en un error estándar y el shell tratará la expansión como un error (el comando no se ejecutará, y si se ejecuta en un shell no interactivo, esto finalizaría). Dejar la :salida activaría el error solo para un valor no establecido, al igual que debajo set -u.

${variable:?word}es una expansión de parámetros POSIX .

Ninguno de estos provocaría la terminación de un shell interactivo a menos que set -e(o set -o errexit) también estuviera en vigor. ${variable:?word}hace que las secuencias de comandos salgan si la variable está vacía o sin establecer. set -uprovocaría la salida de un script si se usa junto con set -e.

En cuanto a tu segunda pregunta. No hay forma de limitar rma no trabajar fuera del directorio actual.

La implementación de GNU rmtiene una --one-file-systemopción que evita que elimine de forma recursiva los sistemas de archivos montados, pero eso es lo más cercano que creo que podemos obtener sin ajustar la rmllamada en una función que realmente verifica los argumentos.

Como nota al margen: ${build}es exactamente equivalente a $buildmenos que la expansión se produzca como parte de una cadena donde el carácter inmediatamente siguiente es un carácter válido en un nombre de variable, como en "${build}x".

Voy a sugerir comprobaciones de validación normales usando test/[ ]

Hubiera estado a salvo si hubiera escrito su guión como tal:

build="build"
...
[ -n "${build}" ] || exit 1
rm -rf "${build}/"*
...

Los [ -n "${build}" ]controles que "${build}"es una cadena de longitud no cero .

El ||es el operador lógico OR en bash. Hace que se ejecute otro comando si falla el primero.

De esta manera, había ${build}estado vacío / indefinido / etc. el script habría salido (con un código de retorno de 1, que es un error genérico).

Esto también lo habría protegido en caso de que eliminara todos los usos ${build}porque [ -n "" ]siempre será falso.

La ventaja de usar test/ [ ]es que hay muchas otras comprobaciones más significativas que también puede usar.

Por ejemplo:

[ -f FILE ] True if FILE exists and is a regular file.
[ -d FILE ] True if FILE exists and is a directory.
[ -O FILE ] True if FILE exists and is owned by the effective user ID.

En su caso específico, he reelaborado la 'eliminación' en el pasado para mover archivos / directorios en su lugar (suponiendo que / tmp esté en la misma partición que su directorio):

# mktemp -d is also a good, reliable choice
trashdir=/tmp/.trash-$USER/trash-`date`
mkdir -p "$trashdir"
...
mv "${build}"/* "$trashdir"
...

Detrás de escena, esto mueve las referencias de archivo / directorio de nivel superior desde las $trashdirestructuras de directorio de origen a destino en la misma partición, y no pasa tiempo recorriendo la estructura del directorio y liberando los bloques de disco por archivo en ese mismo momento. Esto produce una limpieza mucho más rápida mientras el sistema está en uso activo, a cambio de un reinicio un poco más lento (/ tmp se limpia en los reinicios).

Alternativamente, una entrada cron para limpiar periódicamente /tmp/.trash-$USER evitará que / tmp se llene, para procesos (por ejemplo, compilaciones) que consumen mucho espacio en disco. Si su directorio está en una partición diferente como / tmp, puede crear un directorio similar a / tmp-like en su partición y hacer que cron limpie eso en su lugar.

Sin embargo, lo más importante es que si arruinas las variables de alguna manera, puedes recuperar el contenido antes de que ocurra la limpieza.

Use la sustitución de parámetros bash para asignar valores predeterminados cuando las variables no se inicializan, por ejemplo:

rm -rf $ {variable: - "/ nonexistent"}

Siempre trato de comenzar mis scripts de Bash con una línea #!/bin/bash -ue.

-emedios "fallan en la primera uncathed e rror";

-umedios "fallan en primer uso de u ndeclared variable".

Encuentre más detalles en un excelente artículo Utilice el modo estricto de Bash no oficial (a menos que le guste la depuración) . El autor también recomienda usar, set -o pipefail; IFS=$'\n\t'pero para mi propósito esto es excesivo.

El consejo general para verificar si su variable está configurada es una herramienta útil para evitar este tipo de problemas. Pero en este caso había una solución más simple.

Es muy probable que no sea necesario englobar el contenido del $builddirectorio para eliminarlos, pero no el $builddirectorio en sí. Entonces, si omitió lo extraño *, se convertiría en un valor no establecido rm -rf /que, por defecto, la mayoría de las implementaciones de rm en la última década se negarán a realizar (a menos que desactive esta protección con la --no-preserve-rootopción de GNU rm ).

Omitir el seguimiento /también daría como rm ''resultado el mensaje de error:

rm: can't remove '': No such file or directory

Esto funciona incluso si su comando rm no implementa protección para /.

Estás pensando en términos de lenguaje de programación, pero bash es un lenguaje de script :-) Entonces, usa un paradigma de instrucción completamente diferente para un paradigma de lenguaje completamente diferente .

En este caso:

rmdir ${build}

Como rmdirse negará a eliminar un directorio no vacío, primero debe eliminar los miembros. Sabes cuáles son esos miembros, ¿verdad? Probablemente son parámetros para su script, o derivados de un parámetro, por lo tanto:

rm -rf ${build}/${parameter}
rmdir ${build}

Ahora, si coloca algunos otros archivos o directorios como un archivo temporal o algo que no debería tener, rmdirarrojará un error. Manejarlo adecuadamente, luego:

rmdir ${build} || build_dir_not_empty "${build}"

Esta forma de pensar me ha servido bien porque ... sí, he estado allí, hecho eso.