Quand tu fais "ls ..", tu appelles l'exécutable "/bin/ls" avec comme argument le fichier ".." (celui qu'on voit avec "ls -a"), qui est géré par le système de fichiers et qui appartient au vrai répertoire ("tmp/loin/dir"). C'est un genre de lien hard vers le répertoire parent, donc "tmp/loin".
Quand tu fais "cd .." par contre, c'est une commande shell que tu exécutes, et le shell traite cet argument non pas en se référant au système de fichier, mais bien comme un raccourcis pour faire "cd «le path courant moins un répertoire»". Il suit la chaine logique des répertoires et pas celle physique. En pratique, c'est le plus souvent ce qu'on veut effectivement faire, donc c'est pas plus mal. Mais si ça n'est pas ce qu'on veut, c'est désactivable (sous bash au moins : "set -P").
[^] # Re: Par exemple
Posté par tgl . En réponse au message liens symboliques. Évalué à 2.
En fait, c'est bizarre, mais c'est logique.
Quand tu fais "ls ..", tu appelles l'exécutable "/bin/ls" avec comme argument le fichier ".." (celui qu'on voit avec "ls -a"), qui est géré par le système de fichiers et qui appartient au vrai répertoire ("tmp/loin/dir"). C'est un genre de lien hard vers le répertoire parent, donc "tmp/loin".
Quand tu fais "cd .." par contre, c'est une commande shell que tu exécutes, et le shell traite cet argument non pas en se référant au système de fichier, mais bien comme un raccourcis pour faire "cd «le path courant moins un répertoire»". Il suit la chaine logique des répertoires et pas celle physique. En pratique, c'est le plus souvent ce qu'on veut effectivement faire, donc c'est pas plus mal. Mais si ça n'est pas ce qu'on veut, c'est désactivable (sous bash au moins : "set -P").