alias vs export pour des commandes simples

33

Pour des commandes simples comme less, est-il préférable de créer un alias ou d'exporter les options? Y a-t-il un avantage de l'un sur l'autre?

Par exemple, si je veux lesstoujours utiliser l' -Roption d'affichage des caractères bruts, ces deux solutions fonctionnent:

export LESS='-R'
alias less='less -R'

Pour un cas simple comme celui-ci, y a-t-il un avantage de l'un sur l'autre? Des scénarios où l’un causera des problèmes et l’autre ne le fera pas?

Je l' ai lu plusieurs infoet manpages, ainsi que googler, mais je suis toujours bloqué à ce sujet .

bash zsh alias

— quilles
source

1

Non, cela dépend vraiment des préférences personnelles. J'ai voté pour fermer ceci car cela semble plus basé sur l'opinion.

— slm

Trois autres solutions: créer une fonction shell (ne fonctionne que dans le shell mais n’a pas besoin d’être interactive); créer un script dans ~ / bin ou où que ce soit (a un temps système au démarrage du shell mais fonctionne immédiatement avec les shells en cours d'exécution et à partir d'autres programmes, et est persistant); fichiers de configuration spécifiques au programme (car lessvous pouvez le faire en utilisant lesskey)

— deltab

3

@slm Ce n'est pas basé sur l'opinion, ou du moins, ce n'était pas censé l'être. On pourrait avoir besoin de beaucoup plus de temps, et utiliser inutilement des ressources, en particulier dans un scénario plus complexe. On pourrait être conventionnellement plus correct dans le monde * nix, ou peut-être qu'il y a même une norme formelle quelque part. Les programmeurs sont constamment ennuyés par le "codage bâclé", même si, à toutes fins utiles, le même objectif est atteint.

— skittleys

30

Une différence entre les deux est que les alias ne sont qu'une fonctionnalité du shell. Les variables d'environnement sont héritées par tous les sous-processus (à moins d'être délibérément effacées).

La variable d'environnement serait plus susceptible de fonctionner même si lessest lancé indirectement, par exemple via un autre shell (par exemple tcsh), man, vim, psql, etc.

— 200_success
source

3

En particulier, les alias ne fonctionnent que dans les shells interactifs : vous ne pouvez pas les utiliser dans des scripts de shell, ce que vous pouvez parfois souhaiter. bash -c 'alias ll="ls -l"; ll'n'utilisera pas l'alias.

— Deltab

ah, je ne le savais pas! Donc, si j'ai export LESS='-R'dans mon .zshrc, ouvrez une session zsh, puis passez à bash dans cette même session (sans exportation dans .bashrc), la variable d'environnement sera toujours définie? J'aurais pensé que les deux seraient perdus ....

— skittleys

@deltab ah, oui, je connais cette distinction, grâce aux problèmes de coloration de grep. Je vous remercie de le faire remarquer.

— skittleys

1

Cela dépend grandement de l'outil que vous utilisez. Il y aura des outils qui vous permettent d'utiliser l'un ou l'autre, d'autres qui n'en permettent qu'un.

Certaines commandes sont appelées par d'autres, lisent les variables d'environnement et acceptent les mêmes commutateurs, mais leur ajouter le même commutateur est une corvée, comme les compilateurs car make, ici, les variables d'environnement brillent. Vous définissez la variable et oubliez-la. C’est aussi un avantage qu’il puisse être temporel et fonctionner pour une seule commande.

En bout de ligne, il s'agit d'une question de préférences et de meilleure action pour la tâche. Il sera parfois plus facile et permanent de créer un alias qu'une variable d'environnement et d'autres fois, vous aurez besoin d'un éventail d'outils se comportant de la même manière que vous le feriez. variables d'environnement d'amour.

— Braiam
source