J'ai lu il y a quelque temps (je ne trouve pas la référence) que l'utilisation d'un tel alias alias rm="rm -i"
était très mauvaise.
Existe-t-il des preuves historiques ou une explication de bon sens pour ce fait?
J'imagine que cela donne à un utilisateur une mauvaise habitude de s'appuyer sur l'invite de confirmation pour vérifier sa commande, ce qui pourrait entraîner des catastrophes s'il le fait sur un autre profil qui n'a pas l'alias.
Réponses:
Tu as raison.
C'est mauvais parce qu'on s'y habitue. Si vous êtes sur un système qui ne l'a pas, et vous
rm
, il commence immédiatement à être supprimé et vous vous demandez ce qui se passe.De nombreux utilisateurs sont habitués à SSH dans différents systèmes; il est donc assez courant d'utiliser de nombreux systèmes différents, parfois sans configuration de comptes utilisateur personnalisés (y compris les alias).
Utilisez plutôt eg
alias rmi='rm -i'
et apprenez à l'utiliser. Si cela n'est pas configuré sur un autre système, vous n'avez pas supprimé accidentellement des fichiers et pouvez toujours retomber en tapant la commande complète.la source
Comme @Daniel l'a dit, ce n'est pas nocif en soi, à part vous entraîner à vous attendre à ce qu'il soit là. En fait, c'est la configuration par défaut sur les machines CentOS (et par extension RHEL, je suppose - depuis trop longtemps que j'en ai utilisé une), et c'est une douleur énorme pour le tuchus . Pour le reste de mon temps à ce concert, j'ai tapé / bin / rm afin d'éviter la configuration "Linux pour les personnes qui ne devraient pas avoir un accès root".
la source
Je pense que le grand danger est que les gens pourraient compter sur quelque chose comme ça pour filtrer un globe. Imaginez que vous souhaitiez supprimer certaines images d'un répertoire, mais pas toutes:
Vous pouvez l'utiliser pour filtrer le glob manuellement, ce qui serait tout à fait raisonnable. Mais, si vous l'aviez aliasé et que vous l'utilisiez
rm
et que vous aviez atterri dans un shell sans cet alias et l'essayer ... vous venez de supprimer toutes vos photos, oups!Personnellement, je trouve également que cet alias est nocif pour ma tension artérielle;). Mais c'est juste moi.
la source
En plus de ce que Daniel Beck a dit, que je me trouvé à l' aide
-f
de contourner le-i
, ce qui est potentiellement dangereux car elle conduit à l' utilisationrm -f
etrm -rf
inutilement. D'une manière ou d'une autre liée: un moyen de prévenir lesrm -rf
problèmes est de créer un fichier appelé "-i" tel qu'il a été créé en réponse à cette question: Comment puis-je éviter un rm -rf / * accidentel? .Mais encore une fois, si cet alias n'était pas là, je n'utiliserais pas -f, et le tout ne serait pas un problème.
la source
Ceci est beaucoup moins dangereux, d'après mon expérience de travail avec des centaines d'utilisateurs dans le passé:
rm
dans un autre contexte qui n'avait ni cette fonction ni l'rm -i
alias.rm
est intact, laissant les autres programmes intrépides.Le style de code est principalement compatible avec sh (sauf utilisation
echo .... | tr -d '\012'
pour les shells pré-bash), n'hésitez pas à faire votre propre plus spécifique à bash. Je ne poste pas pour partager le code lui-même, mais pour partager le changement d' expérience utilisateur qui l'accompagne.la source
rm -i
historiquement (d'après mon expérience avec des centaines d'utilisateurs), la suppression de fichiers est erronée et que la fonction incluse a formé les utilisateurs à utiliser des caractères génériques corrects à la place, ce qui réduit le taux d'erreur. J'ai donc abordé les problèmes clés qui sévissaientrm -i
et fourni une solution pour des raisons de commodité, et le simple fait que les puces se trouvent sous la fonction ne les empêche pas d'être pertinentes.