Alias temporaire
Tester vite
À créer directement dans le terminal pour une session, une option ou un besoin ponctuel.
Informatique
Un alias Linux est utile quand une commande revient tous les jours : lister un dossier avec les bons détails, suivre un log, ouvrir un projet, lancer un diagnostic réseau ou éviter de retaper une suite d’options. Il devient dangereux quand il masque une commande connue, ajoute un raccourci trop risqué ou laisse un collègue deviner ce que fait réellement le poste.
La règle de base est simple : un alias doit réduire la friction sans cacher l’intention. S’il reçoit des paramètres, prend une décision ou enchaîne plusieurs actions sensibles, il faut passer à une fonction shell ou à un script versionné. Cette migration v4 repart de ce principe pour clarifier les alias temporaires, les alias permanents, les fichiers de démarrage Bash et les garde-fous à poser en équipe.
Un alias est une substitution effectuée par le shell avant l’exécution de la commande. Quand vous tapez le nom de l’alias, Bash le remplace par la commande associée. C’est pratique pour des options répétitives, mais cela reste une substitution textuelle, pas une procédure complète.
Exemple classique : vous voulez afficher souvent les fichiers cachés, les tailles lisibles et les détails du dossier courant. Au lieu de retaper les options, vous créez un alias court.
alias ll='ls -lah'
Ensuite, taper ll lance ls -lah. Le gain paraît modeste, mais il devient réel sur un poste d’administration où les mêmes diagnostics reviennent toute la journée. Le bon alias rend un geste plus lisible; le mauvais alias transforme une commande connue en boîte noire.
Gardez aussi une limite claire : un alias n’est pas fait pour prendre des arguments complexes. Il ne doit pas remplacer une procédure de déploiement, un script de sauvegarde ou une action destructive. Pour ces usages, le raccourci doit pointer vers un outil documenté, pas devenir l’outil lui-même.
Le bon niveau dépend de la fréquence, du risque et de la logique nécessaire.
Tester vite
À créer directement dans le terminal pour une session, une option ou un besoin ponctuel.
Répéter souvent
À placer dans un fichier de démarrage quand le raccourci doit revenir à chaque terminal.
Accepter des paramètres
À préférer si l’action dépend d’un argument, d’un test ou d’une petite logique.
Partager en production
À choisir pour un processus critique, relu, versionné et utilisé par plusieurs personnes.
L’alias temporaire est le bon premier réflexe. Il permet d’essayer un raccourci sans modifier ~/.bashrc, sans gêner une prochaine session et sans imposer votre habitude à d’autres utilisateurs du serveur.
alias maj='sudo apt update && sudo apt upgrade'
Après cette ligne, maj lance la commande complète dans le terminal courant. Pour afficher la définition d’un alias précis, appelez son nom avec la commande alias.
alias maj
Pour voir tous les alias actifs dans la session, lancez simplement :
alias
Et pour retirer le raccourci sans fermer le terminal :
unalias maj
Cette suppression ne touche pas la commande Linux d’origine. Elle retire seulement la substitution active. Si le même alias existe dans un fichier de démarrage, il reviendra au prochain chargement de ce fichier.
Pour conserver un alias entre deux sessions, on l’ajoute souvent dans ~/.bashrc. Ce fichier est lu par Bash pour de nombreux shells interactifs non-login, comme un terminal graphique classique sur une distribution Linux. Le détail compte, car tous les shells ne lisent pas les mêmes fichiers.
Ouvrez d’abord le fichier avec un éditeur que vous maîtrisez. Inutile de rendre ce passage plus compliqué que nécessaire.
nano ~/.bashrc
Ajoutez ensuite une section clairement commentée en fin de fichier. L’objectif est de pouvoir relire la configuration dans six mois, ou de la transmettre à un collègue sans explication orale.
Pour approfondir ce point, consultez réussir ventes marketplace, qui traite plus précisément de réussir ses ventes marketplace sans sacrifier sa marge.
# Alias personnels - administration quotidienne
alias ll='ls -lah'
alias ports='ss -tuln'
alias authlog='sudo tail -f /var/log/auth.log'
alias diskusage='du -sh * | sort -hr | head -20'
Rechargez la configuration dans la session courante, puis testez chaque alias. Si une erreur apparaît, corrigez immédiatement la ligne concernée. Un fichier de démarrage cassé peut polluer tous les nouveaux terminaux.
source ~/.bashrc
type ll
ll
Le point qui surprend le plus n’est pas la syntaxe de l’alias. C’est le fichier qui le charge réellement.
Bash ne lit pas les mêmes fichiers selon qu’il démarre comme shell interactif, shell de login ou shell non interactif. Sur un poste de travail, ~/.bashrc est souvent le bon endroit pour les alias interactifs. Sur certains environnements, ~/.bash_profile, ~/.bash_login ou ~/.profile peuvent intervenir à l’ouverture de session.
La pratique robuste consiste à limiter les alias au contexte interactif et à éviter de les faire dépendre d’un script d’exploitation. Un script doit appeler les commandes complètes ou ses propres fonctions, pas supposer que l’environnement personnel d’un administrateur sera chargé.
Si vous centralisez vos alias dans un fichier séparé, chargez-le depuis ~/.bashrc seulement s’il existe. Cette forme évite une erreur au démarrage du shell.
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
| Fichier | Usage courant | Vigilance |
|---|---|---|
~/.bashrc | Alias et fonctions pour shells interactifs | Ne pas y placer une logique longue ou fragile |
~/.bash_aliases | Fichier séparé pour raccourcis personnels | À charger explicitement depuis ~/.bashrc |
~/.bash_profile | Shell de login Bash selon environnement | Peut ne pas être lu par un terminal graphique classique |
| Script shell | Automatisation partagée ou critique | Ne doit pas dépendre d’alias personnels |
Un alias n’est pas seulement un confort personnel. Sur un poste d’administration, il devient une partie de votre environnement de travail, parfois reproduite sur plusieurs machines. Le nom choisi doit donc être assez court pour servir, mais assez explicite pour ne pas piéger celui qui reprend la session. Le bon nom décrit l’intention plus que la commande exacte.
Évitez les noms qui ressemblent trop à des commandes standards ou à des outils installés par paquets. Un alias nommé ports peut être clair dans une équipe qui l’utilise pour ss -tuln, mais il mérite une vérification si un outil du même nom existe sur certaines distributions. Pour les actions métier, préférez parfois un préfixe, par exemple nx-logs ou pme-disk, afin de signaler qu’il s’agit d’un raccourci local.
Le commentaire est utile quand l’alias dépasse l’évidence. Une ligne ll n’a pas besoin d’un roman. Un raccourci qui lit un log applicatif, interroge un service ou applique un filtre précis mérite une note. Cette documentation légère évite de transformer un gain de dix secondes en enquête de maintenance six mois plus tard.
Révisez aussi votre fichier de temps en temps. Supprimez les alias qui ne servent plus, ceux qui pointent vers des chemins disparus et ceux qui ne correspondent plus aux conventions d’équipe. Un fichier court, relu et vivant reste plus fiable qu’une collection brillante mais abandonnée.
Avant de créer un alias, vérifiez que le nom choisi ne masque pas une commande, un binaire, une fonction ou un autre alias. Les noms très courts sont séduisants, mais ils peuvent rendre le poste ambigu.
type ll
type ports
command -v ports
type indique comment Bash interprète un nom : alias, fonction, builtin, fichier exécutable ou mot-clé. C’est plus utile que de supposer qu’un raccourci est libre. Si le nom existe déjà, choisissez un alias plus explicite.
Évitez aussi de redéfinir des commandes sensibles comme rm, cp, mv ou sudo sans raison solide. Ajouter rm -i peut sembler protecteur sur votre poste, mais devenir dangereux si vous prenez l’habitude d’être protégé partout. Sur un autre serveur, sans cet alias, le geste peut partir sans confirmation.
Un alias de sécurité ne remplace jamais l’attention. Il doit rester un rappel local, pas une garantie opérationnelle.
Un raccourci permanent doit rester prévisible, lisible et facile à désactiver.
Le nom masque-t-il une commande ou une fonction existante ?
Impact décision : Un alias ambigu ralentit le dépannage et perturbe les collègues.
La commande modifie-t-elle des fichiers, services ou droits ?
Impact décision : Plus le risque est élevé, plus il faut préférer un script contrôlé.
Un autre administrateur peut-il comprendre l’intention ?
Impact décision : La lisibilité évite les raccourcis personnels transformés en dette d’exploitation.
Un alias convient aux commandes fixes. Dès que vous devez passer un paramètre, tester une condition ou réutiliser une valeur, une fonction shell devient plus propre. Elle est plus longue à écrire, mais elle évite les alias illisibles qui essaient de tout faire en une ligne.
Exemple : au lieu de créer plusieurs alias de recherche dans /etc, vous pouvez écrire une fonction qui reçoit le terme à chercher.
À lire ensuite, premier script python, consacré à premier script python, partir simple et apprendre sans se perdre.
grepconf() {
grep -R --line-number "$1" /etc 2>/dev/null
}
Après chargement dans le shell, l’appel reste simple :
grepconf "Listen"
La fonction accepte un argument et garde la commande lisible. Pour un besoin plus important, franchissez encore un niveau : créez un script versionné dans un dépôt ou un répertoire d’outillage. L’alias doit rester le raccourci, pas le système de production.
Ce passage au script paraît plus lourd, mais il apporte trois garanties utiles : un historique de modification, une revue possible par un collègue et une exécution identique sur plusieurs machines. Quand une commande touche aux sauvegardes, aux services, aux droits ou aux données client, cette traçabilité vaut largement les quelques minutes gagnées par un alias très compact.
Dans une PME, les alias partagés peuvent accélérer les opérations courantes : diagnostic réseau, suivi de logs, inventaire rapide, navigation dans des dossiers de projet. Ils deviennent problématiques quand chaque administrateur apporte sa collection personnelle sur les serveurs communs. Le résultat est un environnement imprévisible, où deux terminaux voisins ne réagissent plus de la même manière à une commande courte.
La solution n’est pas d’interdire tous les alias. Elle consiste à séparer les raccourcis personnels, les raccourcis d’équipe et les scripts d’exploitation. Les alias personnels restent dans le home de chaque utilisateur. Les alias d’équipe doivent être rares, documentés, relus et compatibles avec les distributions réellement utilisées.
Pour un serveur de production, soyez encore plus strict. Un alias qui redémarre un service, modifie un pare-feu ou purge un dossier doit être remplacé par une procédure écrite ou un script contrôlé. Le confort de frappe ne doit jamais court-circuiter la validation opérationnelle, surtout lorsqu’une commande peut interrompre un service client ou supprimer des fichiers de travail.
Commencez par vérifier s’il est chargé dans la session courante. Beaucoup de problèmes viennent simplement d’un fichier modifié mais pas rechargé.
alias monalias
source ~/.bashrc
Si l’alias n’apparaît toujours pas, contrôlez le fichier utilisé, la présence d’une faute de quote, le nom du shell courant et l’ordre de chargement. Les apostrophes et guillemets sont souvent la source du problème, surtout quand la commande contient déjà des variables ou des redirections.
Le dépannage doit rester méthodique : testez d’abord la commande complète sans alias, puis la définition exacte de l’alias, puis le chargement du fichier. Cette progression évite de modifier trois lignes en même temps et de perdre le vrai signal d’erreur. Sur un poste partagé, notez aussi si le problème existe seulement avec votre utilisateur, avec tous les comptes techniques, ou uniquement dans un type précis de terminal interactif Bash.
Vérifiez ensuite que le nom n’est pas remplacé par autre chose.
type monalias
command -V monalias
Si l’alias fonctionne dans un terminal mais pas dans un script, c’est souvent normal. Les alias sont faits pour les shells interactifs. Dans un script, utilisez une fonction, une variable claire ou la commande complète.
À parcourir avant d’ajouter une ligne dans un fichier de démarrage.
Ces exemples doivent être vus comme des points de départ. Gardez seulement ceux qui correspondent à votre usage réel, et renommez-les si leur intention n’est pas claire dans votre équipe.
alias ll='ls -lah'
alias dfh='df -h'
alias ports='ss -tuln'
alias grep='grep --color=auto'
alias c='clear'
Pour les commandes plus sensibles, ajoutez une validation explicite ou préférez une fonction. Par exemple, un alias de logs avec sudo peut être utile sur un poste d’administration, mais il doit être compréhensible et accepté par l’équipe.
alias authlog='sudo tail -f /var/log/auth.log'
alias journalerr='journalctl -p err -xb'
La meilleure collection d’alias reste courte. Deux ou trois raccourcis vraiment utilisés valent mieux qu’un fichier de cinquante lignes que personne ne relit.
Créez d’abord l’alias en temporaire, utilisez-le, puis décidez s’il mérite une place dans ~/.bashrc ou dans un fichier séparé. Vérifiez le nom, documentez l’intention, rechargez proprement et testez dans une nouvelle session. Si le raccourci devient plus intelligent qu’une simple substitution, arrêtez l’alias et écrivez une fonction ou un script.
La prochaine action est simple : choisissez une seule commande que vous retapez trop souvent, créez un alias temporaire, testez-le une journée, puis gardez-le seulement s’il rend votre travail plus clair.
Pour approfondir ce point, consultez linux commands, qui traite plus précisément de linux commands utiles avant d’agir en terminal.
À lire aussi