Y a-t-il des inconvénients à définir «noclobber»?

Étant donné que zshpeut assommer tous les fichiers avec la commande:

>*

Je pense que définir l'option noclobberserait une bonne idée.

Je peux toujours utiliser >| filesi je veux utiliser le comportement de clobber par défaut dans bash et zsh. (zsh autorise également la syntaxe alternative >!file).

Je suppose que ce noclobbern'est pas réglé par défaut à cause de la compatibilité POSIX, mais juste pour être sûr:

Y a-t-il des inconvénients à la configuration noclobber?

Est-il possible de définir noclobberuniquement pour le shell interactif?

La raison noclobbern'est pas définie par défaut est la tradition. En ce qui concerne la conception de l'interface utilisateur, c'est une bonne idée de faire de "créer ce nouveau fichier" l'action facile et de mettre un obstacle supplémentaire l'action la plus dangereuse "soit créer un nouveau fichier ou écraser un fichier existant". C'est donc noclobberune bonne idée ( >pour créer un nouveau fichier, >|pour écraser potentiellement un fichier existant) et ce serait probablement la valeur par défaut si le shell avait été conçu quelques décennies plus tard.

Je recommande fortement d'utiliser ce qui suit dans votre fichier de démarrage du shell interactif ( .bashrcou .zshrc):

set -o noclobber
alias cp='cp -i'
alias mv='mv -i'

Dans chaque cas (redirection, copie, déplacement), l'objectif est d'ajouter un obstacle supplémentaire lorsque l'opération peut avoir pour effet secondaire d'effacer certaines données existantes, même si l'effacement des données existantes n'est pas l'objectif principal de l'opération. Je ne mets pas rm -idans cette liste car l'effacement des données est l'objectif principal de rm.

Notez cela noclobberet ce -isont des filets de sécurité . S'ils se déclenchent, vous avez fait quelque chose de mal . Ne les utilisez donc pas comme excuse pour ne pas vérifier ce que vous écrasez! Le fait est que vous devriez avoir vérifié que le fichier de sortie n'existe pas. Si on vous dit file exists: fooou overwrite 'foo'?, cela signifie que vous avez fait une erreur et que vous devriez vous sentir mal et être plus prudent. En particulier, ne prenez pas l'habitude de dire ysi vous êtes invité à écraser (sans doute, les alias devraient l'être alias cp='yes n | cp -i' mv='yes n | mv -i', mais en appuyant sur Ctrl+, Cla sortie est meilleure): si vous vouliez écraser, annuler la commande, déplacer ou supprimer la sortie fichier et réexécutez la commande.

Il est également important de ne pas prendre l'habitude de déclencher ces sécurités car si vous le faites, vous serez un jour sur une machine qui n'a pas votre configuration, et vous perdrez des données car les protections sur lesquelles vous comptiez ne sont pas '' t là.

noclobberne sera défini que pour les shells interactifs, car .bashrcou .zshrcn'est lu que par les shells interactifs. Bien sûr, vous ne devez pas modifier les options du shell d'une manière qui affecterait les scripts, car cela pourrait casser ces scripts.

La définition de l' noclobberoption shell dans ~/.bashrc(pour bash) ou ~/.zshrc(ou plus précisément $ZDOTDIR/.zshrcpour zsh) la rendra active dans les sessions shell interactives.

Les shells (scripts) non interactifs ne lisent pas ces fichiers.

Les options de shell ne sont généralement pas héritées des shells parents.

Cela signifie que vous devriez pouvoir définir l'option dans ces fichiers sans modifier le comportement des scripts existants, à moins que les scripts ne sources explicitement ces fichiers.

Le seul inconvénient de cela, c'est que vous oublierez à plusieurs reprises que vous avez défini l'option, au moins au début. Plus tard, comme avec tout ce genre de choses, vous commencerez à utiliser habituellement >|, même dans les cas où vous ne voudrez pas réellement encombrer le fichier (tout comme les personnes avec des alias pour rm, cpet mvavec l' -ioption toujours définie, finissent par commencer à toujours utiliser -fsur la ligne de commande).

L'inconvénient est que, si vous vous habituez à être noclobberactif, vous utiliserez un jour un système où il ne sera pas actif et vous exécuterez allègrement une commande potentiellement dangereuse, en espérant que cela noclobbervous sauvera ... et ce ne sera pas le cas. Et puis vous devrez espérer qu'il existe une sauvegarde assez récente pour récupérer les données que vous avez détruites car vous supposiez que l'on vous demanderait d'abord une confirmation.