Comment puis-je renforcer les scripts bash pour ne pas nuire lors de modifications ultérieures?

J'ai donc supprimé mon dossier personnel (ou plus précisément tous les fichiers auxquels j'avais accès en écriture). Qu'est-ce qui s'est passé, c'est que j'avais

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

dans un script bash et, après ne plus en avoir besoin $build, supprimer la déclaration et tous ses usages - sauf le rm. Bash s'étend joyeusement à rm -rf /*. Oui.

Je me suis senti stupide, installé la sauvegarde, refait le travail que j'ai perdu. Essayer de dépasser la honte.

Maintenant, je me demande: quelles sont les techniques pour écrire des scripts bash afin que de telles erreurs ne puissent pas se produire, ou du moins soient moins probables? Par exemple, avais-je écrit

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

dans un script en ruby, l'interprète se serait plaint de buildne pas avoir été déclaré, donc le langage me protège.

Ce que j’ai envisagé lors de bash, outre le corraling rm(qui, comme le soulignent de nombreuses réponses à des questions connexes, n’est pas sans poser de problèmes):

1. rm -rf "./${build}/"*
   Cela aurait tué mon travail actuel (un dépôt Git) mais rien d’autre.
2. Une variante / paramétrage de rmcette opération nécessite une interaction lorsque vous agissez en dehors du répertoire en cours. (Impossible d'en trouver.) Effet similaire.

Est-ce le cas ou existe-t-il d'autres moyens d'écrire des scripts bash "robustes" en ce sens?

set -u

ou

set -o nounset

Cela ferait en sorte que le shell actuel traite les développements de variables non définies comme une erreur:

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

set -uet set -o nounsetsont des options de shell POSIX .

Une valeur vide ne déclencherait cependant pas d'erreur.

Pour cela, utilisez

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

L'expansion de ${variable:?word}serait étendue à la valeur de variablesauf si elle est vide ou non définie. S'il est vide ou non défini, l'icône wordserait affichée en cas d'erreur standard et le shell traiterait l'extension comme une erreur (la commande ne serait pas exécutée et, si elle était exécutée dans un shell non interactif, elle se terminerait). Si vous laissez la :sortie, l'erreur ne serait déclenchée que pour une valeur non définie, tout comme sous set -u.

${variable:?word}est une extension de paramètre POSIX .

Ni l'un ni l'autre ne provoquerait la fermeture d'un shell interactif à moins que set -e(ou set -o errexit) ne soit également en vigueur. ${variable:?word}provoque la fermeture des scripts si la variable est vide ou non définie. set -uprovoquerait la fermeture d'un script s'il était utilisé avec set -e.

Quant à votre deuxième question. Il n'y a aucun moyen de limiter rmpour ne pas travailler en dehors du répertoire en cours.

L’implémentation GNU de rma une --one-file-systemoption qui l’empêche de supprimer de manière récursive les systèmes de fichiers montés, mais je pense que c’est aussi proche que nous pouvons obtenir sans insérer l’ rmappel dans une fonction qui vérifie réellement les arguments.

Comme note latérale: ${build}est exactement équivalent à $buildmoins que le développement ne se produise en tant que partie d’une chaîne où le caractère immédiatement suivant est un caractère valide dans un nom de variable, tel que dans "${build}x".

Je vais proposer des contrôles de validation normales en utilisant test/[ ]

Vous auriez été en sécurité si vous aviez écrit votre script en tant que tel:

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

Les [ -n "${build}" ]vérifications qui "${build}"sont une chaîne de longueur non nulle .

Le ||est l'opérateur OU logique en bash. Une autre commande sera exécutée si la première a échoué.

De cette façon, avait ${build}été vide / indéfini / etc. le script aurait quitté (avec un code de retour de 1, qui est une erreur générique).

Cela vous aurait également protégé au cas où vous auriez supprimé toutes les utilisations, ${build}car ce [ -n "" ]sera toujours faux.

L'avantage d'utiliser test/ [ ]est qu'il y a beaucoup d'autres contrôles plus significatifs qu'il peut également utiliser.

Par exemple:

[ -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.

Dans votre cas particulier, j'ai déjà retravaillé le terme "suppression" pour déplacer des fichiers / répertoires (en supposant que / tmp se trouve sur la même partition que votre répertoire):

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

En coulisse, cela déplace les références de fichier / $trashdirrépertoire de niveau supérieur des structures de répertoires source vers la destination, sur la même partition, sans perdre de temps à parcourir la structure de répertoires et à libérer les blocs de disque par fichier immédiatement. Cela produit un nettoyage beaucoup plus rapide lorsque le système est en cours d'utilisation active, en contrepartie d'un redémarrage légèrement plus lent (/ tmp est nettoyé au redémarrage).

Sinon, une entrée cron pour nettoyer périodiquement /tmp/.trash-$USER empêchera / tmp de se remplir, pour les processus (par exemple, les constructions) qui utilisent beaucoup d’espace disque. Si votre répertoire se trouve sur une autre partition que / tmp, vous pouvez créer un répertoire similaire à / tmp sur votre partition et laisser cron le nettoyer.

Mais surtout, si vous bousillez les variables de quelque manière que ce soit, vous pouvez récupérer le contenu avant le nettoyage.

Utilisez la substitution bash paramater pour attribuer des valeurs par défaut lorsque les variables ne sont pas initialisées, par exemple:

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

J'essaie toujours de démarrer mes scripts Bash avec une ligne #!/bin/bash -ue.

-edes moyens « échouent sur la première uncathed e rror »;

-udes moyens « échouent sur la première utilisation de u ndeclared variable ».

Trouvez plus de détails dans un article de qualité Utilisez le mode strict non officiel de Bash (sauf si vous aimez le débogage) . Aussi l'auteur recommande d'utiliser, set -o pipefail; IFS=$'\n\t'mais pour mes fins, c'est exagéré.

Le conseil général pour vérifier si votre variable est définie est un outil utile pour éviter ce genre de problème. Mais dans ce cas, il y avait une solution plus simple.

Il n’est probablement pas nécessaire de déplacer le contenu du $buildrépertoire pour les supprimer, mais pas le $buildrépertoire lui-même. Donc, si vous ignorez ce qui est superflu, *alors une valeur non définie se transformera en rm -rf /laquelle, par défaut, la plupart des implémentations de rm de la dernière décennie refuseront d’être exécutées (sauf si vous désactivez cette protection avec l’ --no-preserve-rootoption de GNU rm ).

Sauter la fin /également rm ''entraînerait le message d'erreur suivant:

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

Cela fonctionne même si votre commande rm n'implémente pas de protection pour /.

Vous pensez en termes de langage de programmation, mais bash est un langage de script :-) Utilisez donc un paradigme d’ instruction totalement différent pour un paradigme de langage totalement différent .

Dans ce cas:

rmdir ${build}

Étant donné rmdirque refusera de supprimer un répertoire non vide, vous devez d'abord supprimer les membres. Vous savez ce que sont ces membres, non? Ce sont probablement des paramètres de votre script, ou dérivés d'un paramètre, donc:

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

Maintenant, si vous mettez d’autres fichiers ou répertoires dedans comme un fichier temporaire ou quelque chose que vous n’auriez pas dû, le rmdirjettera une erreur. Manipulez-le correctement, puis:

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

Cette façon de penser m'a bien servi parce que ... oui, j'ai été là.