`alias rm =“ rm -i ”` considéré comme nuisible?

17

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.

Dunaril
la source
Je pense avoir trouvé le sujet que vous avez mentionné.
Daniel Beck
1
@Daniel en effet la réponse la plus votée de ce fil mentionne cette mauvaise pratique, mais ce n'est pas vraiment le sujet central de la question.
Dunaril

Réponses:

36

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.

Daniel Beck
la source
4

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

Andrew Beals
la source
3
RHEL a cela par défaut, vous avez raison, au moins les systèmes que j'ai utilisés.
Daniel Beck
4

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:

rm -i pics/*.jpg

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

Erreur fatale
la source
Bel exemple. Bien sûr, si vous aimez le danger ou le jeu.
Dunaril
2

En plus de ce que Daniel Beck a dit, que je me trouvé à l' aide -fde contourner le -i, ce qui est potentiellement dangereux car elle conduit à l' utilisation rm -fet rm -rfinutilement. D'une manière ou d'une autre liée: un moyen de prévenir les rm -rfproblè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.

lupincho
la source
3
On dirait que vous avez trouvé un moyen d'aggraver cette mauvaise pratique :)
Dunaril
0

Ceci est beaucoup moins dangereux, d'après mon expérience de travail avec des centaines d'utilisateurs dans le passé:

rm ()  # must be a function, must require single answer for all targets
{
    ls -FCsd "$@"
    local reply ; echo -n 'remove[ny]? ' ; read reply
    if [ "_$reply" = "_y" ] ; then
        /bin/rm -rf "$@" ; else echo '(cancelled)'
    fi
}
  • Les utilisateurs sont formés pour utiliser correctement les caractères génériques, pas seulement «*», puis en s'appuyant sur les invites y / n pour sélectionner les fichiers
  • Le conditionnement pour utiliser des caractères génériques corrects a souvent sauvé le désastre lorsqu'ils étaient utilisés rmdans un autre contexte qui n'avait ni cette fonction ni l' rm -ialias.
  • J'ai passé moins de temps à restaurer des fichiers où l'utilisateur a tapé «y» une fois de plus
  • Les utilisateurs ne doivent répondre qu'une seule fois - fournissant un retour positif net à leur utilisation
  • Control-c interrompt le travail et signale que cela ne fait rien
  • Ce n'est pas un script, donc le réel rmest 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.

Alex North-Keys
la source
Kamil: Ma réponse comprend que, rm -ihistoriquement (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évissaient rm -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.
Alex North-Keys