Pourquoi l'aliasing sur les commandes standard n'est-il pas recommandé?


19

Par exemple, un alias commun que j'ai vu dans le ~/.bashrcfichier (ou équivalents) est

alias rm='rm -i'

Cependant, j'ai vu des gens déconseiller cela parce que

  1. l'alias peut ne pas exister sur un autre système et puisque vous êtes devenu imprudent avec rm, vous supprimez par inadvertance quelque chose d'important. [1]
  2. en utilisant cet alias, vous vous entraînez en effet à taper you yesaprès chaque rmcommande, ce qui va à l'encontre du but recherché.

Y a-t-il d'autres raisons de déconseiller cela? Certains programmes peuvent-ils simplement appeler au rmlieu de \rm, et leur alias pourrait leur causer des problèmes?

J'utilise rmsimplement comme exemple, mais j'ai vu d'autres commandes comme cpou mvcouvertes par des alias également. Personnellement, je m'entraîne lentement à utiliser un alias comme celui-ci à la place de rm -i:

alias trash=`mv -v -t $HOME/.Trash`

3
Chaque fois que je trébuche sur un système avec un alias par défaut rm -i, cela m'entraîne un peu plus à ajouter automatiquement le -fdrapeau.
Jander

Vous pouvez créer un alias rm -ipour tout ce que vous voulez. Tels que del, irmetc. Vous n'avez pas besoin de l'aliaser rm. Cela contourne le point 1, et en utilisant sélectivement delou rmselon ce que vous voulez, vous contournez également le point 2 dans une certaine mesure.
Martin Tournoij

Réponses:


8

En supposant que vous utilisez bash, cela ne devrait pas causer de problèmes pour les scripts, car les shells bash non interactifs ne sont pas sources ~/.bashrcou ~/.bash_profile(ce qui est probablement soit où vos alias sont placés, soit la première étape pour obtenir vos alias dans un autre script) . Cependant, cela peut entraîner des problèmes si vous recherchez des scripts:

$ alias echo='command echo foo'
$ cat > script << 'EOF'
> #!/bin/bash
> echo bar
> EOF
$ chmod a+x script
$ ./script
bar
$ . ./script
foo bar

Votre question couvre la plupart des préoccupations générales concernant l'aliasing sur les commandes existantes, la principale étant que des environnements inconnus qui semblent à première vue être les mêmes pourraient potentiellement produire des résultats extrêmement différents. Par exemple, l' aliasing rmde rm -ibonnes intentions, mais il est mauvais dans la pratique pour les raisons que vous l' Etat.


7

"Y a-t-il d'autres raisons de déconseiller cela?"

Bien sûr:

(3) Parce qu'un jour j'espère ajouter aux fondations construites par les gens [-----------] et paranoïaques qui châtient les autres pour aliaser les commandes standard, même si l'aliasing des commandes standard est, eh bien, standard .

Sérieusement, ce ne sont que des mises en garde. Si vous vous faites confiance pour ne pas tomber dans l'un de ces puits de malheur, alors méfiez-vous et allez-y.

Personnellement, je alias très peu de commandes standard; J'utilise de légères variations car je suis, un peu, paranoïaque et rétentif anal. Mais une bonne utilisation que j'ai trouvée pour cela concerne les systèmes où je me connecte souvent en tant que root ou un autre utilisateur, et il y a des choses que je ne veux pas exécuter accidentellement / paresseusement en tant que root:

alias irc="echo \"No you don't!\""

ou

alias irc="su irc_user"

4

À titre d'exemple extrême, permettez-moi simplement d'alias une commande standard pour illustrer pourquoi l'aliasing des commandes standard peut être nuisible:

alias ls='rm'

Évidemment, c'est mauvais car cela provoquerait un jour une mauvaise surprise. De même, le remplacement des commandes standard par des alias conduira éventuellement à une surprise malheureuse lorsque vous vous y attendez le moins.

Mais permettez-moi de présenter un scénario commun qui arrivera à presque tous les administrateurs Unix à mesure qu'ils avancent dans leur carrière:

Un jour, vous commencerez un nouvel emploi et travaillerez sur un nouveau système qui a été mis en place par d'autres. Il sera trois heures du matin samedi et vous ne pensez pas droit et êtes enclin à faire des erreurs. Votre environnement standard ne sera pas disponible. En fait, vous êtes root.

Compte tenu de cela, allez-vous vous rappeler que ce rmn'est pas un alias rm -i? Allez-vous vérifier vos alias spéciaux chaque fois que vous vous connectez à la boîte? Si vous changez l'environnement de root, vos collègues seront-ils satisfaits de votre changement?

Je suis honnêtement sur la clôture à ce sujet. J'ai travaillé sur des milliers de systèmes au cours de ma carrière, et si je modifiais l'environnement sur tous ces systèmes, il serait difficile d'en voir la valeur.

Aliasing rmà rm -iest très commun et je l' ai vu à prévenir de nombreux problèmes, mais il a également provoqué de nombreuses surprises et des heures de travail supplémentaire pour récupérer des fichiers supprimés accidentellement.

Alors maintenant, j'essaie d'éviter d'aliaser les commandes système courantes. Au lieu de cela, j'utilise des alias et des fonctions pour faire des choses que le shell ne peut pas faire facilement. Ce que j'ai tendance à faire maintenant, c'est d'attacher une lettre supplémentaire à l'alias, comme:

# List long, with color or special characters, depending on OS
alias  ll='ls -l'
# Long, with metacharacters, show dotfiles, don't show . and ..
alias lll='ls -lA'
# Long, with metacharacters, show dotfiles, show . and ..
alias lla='ls -la'
# List just the dotfiles
alias  l.='ls -l -Ad .????*'

# Useful greps
#alias hgrep='history |grep ${*} |grep -v $$'
alias greph='history |grep ${*}'
alias grepp='ps -ef |grep ${*}'

### Highlight some text.
# From http://unix.stackexchange.com/questions/366/convince-grep-to-output-all-lines-not-just-those-with-matches/367#367
highlight () { grep --color -E "$1|$" $2 ; }

Et peut-être que je devrais vraiment me débarrasser de mon dernier alias, car l'adaptation aux nouvelles pratiques prend du temps:

# For safety!
alias rm='rm -i'

8
Se souvenir des drapeaux pour lspourrait être plus pratique que de se souvenir de dix alias.
Bernhard

Très vrai. Et en fait, j'utilise rarement ces alias. Je ne sais pas pourquoi je les ai toujours, à part les alias (et fonctions) les plus compliqués qui étaient difficiles à comprendre et sont bons pour référence. Pour plus de simplicité, je devrais probablement les supprimer.
Stefan Lasiewski

L '"illustration" (premier exemple) n'est pas vraiment utile. C'est clairement malveillant, et nous savons que piéger un système peut être dangereux. Votre rm-> rm -iexemple est bien meilleur. Un autre bon serait celui qui alias rm pour mettre les choses dans un~/.trash
derobert

1
@Bernhard: Vrai, mais les alias sont plus rapides à taper. (Mais dix, c'est trop, peu importe.)
Emanuel Berg

2
@StefanLasiewski: Astuce: ne supprimez jamais des éléments qui ne s'affichent pas, pour des raisons purement esthétiques. Laissez-les rester à moins qu'ils ne vous dérangent activement. C'est un acte tellement rapide d'enlever des trucs après avoir passé des heures à les installer; et si jamais vous le regrettez, vous vous sentez idiot de ne pas les avoir laissés faire.
Emanuel Berg

4

Il y a plus de dangers.

Par exemple, si vous utilisez shell-commanddans Emacs, vous pourriez penser que vous obtenez "votre" commande (ou alias , mais vous n'avez pas besoin de frapper un lsalias dans un terminal qui plusieurs fois avant d'oublier la configuration de l'alias, en pensant à comme n'importe quelle autre commande ...) - en fait (retour à Emacs), vous obtenez la commande (sans biais). Emacs l'exécutera sans problème, vous pourriez même être aveugle à ce qui vient de se passer!

En ce qui concerne différents ordinateurs et / ou systèmes, si vous pensez qu'il est trop fastidieux de configurer des .rcfichiers individuels pour tous, vous pouvez simplement avoir un tel fichier, mais avec des ifclauses à personnaliser.

Par exemple, au lieu d'évaluer chaque fonction lorsque vous les écrivez, juste au moment où vous rencontrez des problèmes avec l'une d'entre elles, ajoutez-les à la "liste noire", en dernier:

if [[ `uname` == "SunOS" ]]; then
  unset -f mic cpkeep mcp mcph cpindex cpconf # not for Solaris
fi

3

Renommer les commandes standard par des alias (c'est-à-dire les rm=rm -i) choses peut certainement conduire à des surprises lorsque l'alias n'est pas disponible. Je préfère ne pas en utiliser, et (par plusieurs expériences amères, amères ;-) Je me suis habitué à lire deux fois chaque commande, et si c'est rmou mvou autre chose potentiellement destructrice trois fois. Et de tels alias mènent à "rm foo" automatique "ENTER" y " Oups !! de toute façon (et coûte une pression de touche supplémentaire à chaque fois).

Mais c'est juste moi. Si vous ne vous attendez pas à fonctionner dans des environnements extraterrestres (autres machines, autres utilisateurs, ...) et que vous pouvez installer vos alias préférés où que vous soyez, allez-y. Unix est connu pour donner aux utilisateurs plus de suffisamment de corde pour tirer leurs propres pieds.


0

Les autres réponses sont bonnes, mais elles ne font que regarder comment cela vous affecte.

Permettez-moi de tourner un peu la réponse de @Stephan Laswieski.

En supposant que vous n'êtes pas omniscient, vous devrez peut-être demander à quelqu'un d'autre de travailler sur votre compte d'utilisateur ou de vous conseiller sur la façon de faire quelque chose.

Ensuite, quand ils font quelque chose ou vous disent de le faire, cela peut ne pas fonctionner comme prévu.

Au mieux, vous devrez perdre du temps à leur expliquer ce qui s'est passé (si vous êtes là et que vous pouvez vous souvenir ou comprendre que l'alias est à l'origine du problème).

Au pire, voyez une variante de l'exemple dans l'une des autres réponses: alias ls = 'rm -rf'.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.