On travaille sur un projet avec une arborescence profonde, on saute dans un répertoire de configuration pour modifier un fichier, puis on veut revenir exactement là où on était. Taper le chemin complet à chaque fois, ou enchaîner les cd .. jusqu’à retrouver le bon dossier, finit par ralentir le flux de travail. C’est précisément le problème que popd résout, en combinaison avec pushd et la pile de répertoires du shell.
Pile de répertoires dans Bash : le mécanisme derrière popd
Avant de parler de popd, il faut comprendre ce qu’on manipule. Le shell maintient une pile (stack) de chemins de répertoires. Chaque appel à pushd empile le répertoire courant, puis nous déplace vers le répertoire spécifié. Popd fait l’opération inverse : il dépile le dernier chemin enregistré et nous y ramène.
A voir aussi : Les points clés à connaître sur le système d'alerte en temps réel
La commande dirs affiche l’état de cette pile à tout moment. En pratique, on obtient une liste ordonnée de chemins, le sommet de la pile étant à gauche. C’est un fonctionnement LIFO (Last In, First Out), identique à une pile d’assiettes.
Ce trio de commandes (pushd, popd, dirs) fait partie des commandes intégrées (builtins) de Bash. La documentation de référence Debian les inclut dans les pratiques recommandées pour la navigation en ligne de commande, ce qui confirme qu’on ne parle pas d’un outil marginal.
A voir aussi : INSA Rouen webmail expliqué aux nouveaux inscrits : mode d'emploi complet
Popd en situation réelle : scripts et navigation manuelle
Imaginons un script de déploiement. On part de /home/user/projet, on doit aller modifier un fichier dans /etc/nginx/sites-available, puis revenir au répertoire de travail initial pour lancer une commande de build. Avec cd, il faut stocker manuellement le chemin dans une variable ou le retaper. Avec pushd et popd, deux lignes suffisent.
Exemple concret dans un script Bash
On écrit pushd /etc/nginx/sites-available, on fait nos modifications, puis on appelle popd. Le shell nous ramène dans /home/user/projet sans qu’on ait eu à mémoriser quoi que ce soit. La pile a fait le travail.
Ce mécanisme devient particulièrement utile quand on enchaîne plusieurs sauts. On peut empiler trois ou quatre répertoires avec des appels successifs à pushd, puis revenir en arrière répertoire par répertoire avec popd. La commande dirs -v affiche la pile numérotée verticalement, ce qui aide à visualiser l’ordre de retour.
Gestion d’erreur quand la pile est vide
Un point que la plupart des tutoriels survolent : que se passe-t-il quand on appelle popd sur une pile vide ? Sur Bash, la commande renvoie une erreur explicite (« directory stack empty ») et ne change pas de répertoire. C’est un comportement fiable pour les scripts, parce qu’on peut tester le code de retour et agir en conséquence.
Dans un script robuste, on écrit quelque chose comme :
- pushd /chemin/cible pour empiler et se déplacer, en vérifiant le code de retour
- Les commandes de travail dans le répertoire cible
- popd pour revenir, avec une condition de fallback si la pile est vide
Cette gestion d’erreur propre distingue pushd/popd d’un simple cd suivi d’un cd – (qui ne retient qu’un seul répertoire précédent).
Popd avec arguments : naviguer dans la pile par index
Popd ne se limite pas à dépiler le sommet. On peut cibler un élément précis de la pile avec un argument numérique. La syntaxe popd +N retire l’entrée située à la position N (en comptant depuis le sommet, à partir de zéro). La variante popd -N compte depuis le bas de la pile.
En pratique, on utilise d’abord dirs -v pour voir la pile numérotée, puis on cible l’entrée à retirer. C’est utile quand on a empilé plusieurs répertoires et qu’on veut en nettoyer un au milieu sans toucher aux autres.
Les retours varient sur ce point selon les habitudes : certains préfèrent vider la pile entièrement et repartir de zéro plutôt que de manipuler des index. C’est une question de lisibilité du script plus que de performance.
Différences de comportement entre shells et environnements
Popd existe dans Bash, Zsh, et dans des shells Windows comme PowerShell ou Take Command (JPSoft). Les bases sont les mêmes, mais les options et le comportement en cas d’erreur diffèrent selon le shell.
- Sur Bash et Zsh, popd est un builtin strict : pile vide = erreur, pas de changement de répertoire
- Sur Take Command (JPSoft), popd accepte des options comme /X pour exclure des entrées, et permet de dépiler N éléments d’un coup ou de cibler par nom
- Sur PowerShell, les commandes équivalentes sont Push-Location et Pop-Location, avec une logique similaire mais une syntaxe différente
- La portabilité entre shells n’est pas garantie : un script qui utilise popd +2 sur Bash fonctionnera sur Zsh, mais la syntaxe JPSoft est incompatible
Pour des scripts destinés à tourner dans plusieurs environnements, mieux vaut s’en tenir à l’usage basique de popd sans argument, qui reste le dénominateur commun.
Pushd et popd face à cd : quand choisir quoi
On n’a pas besoin de pushd/popd pour tout. Si on navigue entre deux répertoires, cd – suffit pour basculer entre le répertoire courant et le précédent. C’est rapide et sans pile à gérer.
Pushd et popd prennent leur sens dès qu’on travaille avec trois répertoires ou plus, ou dans un script qui doit revenir à son point de départ après une série d’opérations dans des chemins variés. La pile agit comme un historique structuré, là où cd – ne retient qu’un seul chemin.
Un cas d’usage fréquent : les scripts d’intégration continue qui compilent dans un répertoire de build, copient des fichiers dans un répertoire de sortie, mettent à jour une configuration ailleurs, puis reviennent au point de départ. Chaque étape utilise pushd à l’aller et popd au retour, ce qui rend le script lisible et réversible.
La pile de répertoires reste un outil de navigation, pas de gestion de fichiers. Elle ne remplace ni find, ni les variables d’environnement pour stocker des chemins importants. Mais pour le va-et-vient entre dossiers pendant une session de travail ou dans un script de déploiement, popd et pushd éliminent les erreurs de chemin et raccourcissent le code de façon mesurable.
