Comment savoir si je suis réellement à un emplacement de lien symbolique depuis la ligne de commande?

33

Supposons que j'ai un dossier:

cd /home/cpm135/public_html

et faire un lien symbolique

ln -s /var/lib/class .

Plus tard, je suis dans ce répertoire:

cd /home/cpm135/public_html/class

Le pwdva me dire que je suis dedans/home/cpm135/public_html/class

Y a-t-il un moyen de savoir que je suis "vraiment" dedans /var/lib/class? Merci

— Oliver Williams
source

2

Connexe: étrange différence entre pwd et / bin / pwd .

— Scott

1

Certains coques ne vous permettent pas réellement d'être à l'intérieur d'un lien symbolique. Par exemple, le fishshell résout automatiquement le lien symbolique lorsque vous y entrez cd.

— Trysis

56

Selon la pwdconfiguration de votre commande, le répertoire de travail logique (sortie par pwd -L), qui affichera l'emplacement du lien symbolique, ou le répertoire de travail physique (sortie par pwd -P), qui ignore le lien symbolique et affiche le répertoire "réel" , peut s'afficher par défaut .

Pour des informations complètes, vous pouvez faire

file "$(pwd -L)"

À l'intérieur d'un lien symbolique, cela retournera

/path/of/symlink: symbolic link to /path/of/real/directory

— Zanna
source

1

oui, le -Pdrapeau était ce dont j'avais besoin. Merci

— Oliver Williams

6

Pour répondre également à la question dans le titre, utilisez simplement test "$(pwd -L)" = "$(pwd -P)" && echo No symlinks(ou remplacez && echo No symlinkspar || echo Symlinks).

— un CVn

1

Cela répond parfaitement à la question sans avoir besoin de faire écho. Si la question était "Comment puis-je afficher un message si je suis dans un répertoire symlinked?", Alors l'écho serait requis.

— Arronical

file "$(pwd)"ne fonctionne que si le lien symbolique est le dernier composant du répertoire. Il ne détecte pas le lien symbolique de l'OP lorsqu'il est gravé sur CD /home/cpm135/public_html/class/foo/bar. Je ne suis pas au courant de quoi que ce soit qui imprime des informations pour tous les liens symboliques dans un chemin d'accès, mais vous pouvez également utiliser realpath ., ce qui, à mon avis, équivaut àpwd -P

— Peter Cordes

17

Notez que pwdc'est en fait un shell intégré. Selon votre shell et sa configuration, les résultats peuvent changer. Pour une solution plus portable, vous devriez utiliser /bin/pwd. Extrait de la page de manuel:

NAME
       pwd - print name of current/working directory

SYNOPSIS
       pwd [OPTION]...

DESCRIPTION
       Print the full filename of the current working directory.

       -L, --logical
              use PWD from environment, even if it contains symlinks

       -P, --physical
              avoid all symlinks

       --help display this help and exit

       --version
              output version information and exit

       If no option is specified, -P is assumed.

       NOTE:  your  shell  may  have  its  own  version of pwd, which usually supersedes the version described here.  Please refer to your shell's documentation for
       details about the options it supports.

En général, vous pouvez résoudre le chemin canonique complet de tout fichier / répertoire à l'aide de readlink -f. readlink -f .fonctionne similaire à pwd -P.

— Gowtham
source

2

Bien que j'ai appris à la dure qui readlink -fn'est pas disponible sur tous les Unices (par exemple, non disponible sur OS-X)

— abligh

3

Vous êtes vraiment dedans /home/cpm135/public_html/class- c'est la seule réponse correcte à la question "quel est mon répertoire de travail actuel".

Quand vous parlez de /var/lib/class… ce n’est pas vraiment votre position, mais celle du chemin que vous utilisiez auparavant .

Lorsque vous exécutez /bin/pwd, il détermine votre répertoire de travail actuel en consultant le. et .. les répertoires (ceux listés en haut de ls -la), en déterminant quel répertoire dans .. correspond à. et puis en arrière jusqu'à ce que… et. se référer au même répertoire. Une fois que tout est fait, il sait quel est votre répertoire de travail actuel.

Lorsque vous exécutez le pwdshell intégré, il ne suit pas cette procédure (bien qu'il puisse en effectuer une partie si nécessaire). Il se souvient du chemin que vous avez emprunté pour arriver ici. Ainsi, chaque fois que vous exécutez une cdcommande, votre shell s'en souvient dans le cadre du chemin pour vous rendre où vous êtes maintenant, et pwdaffiche ce qu'il a calculé en fonction de toutes les cdcommandes que vous avez effectuées - ce qui peut être ou non votre véritable commande. directeur de travail.

Les choses peuvent devenir vraiment bizarres lorsque vous ln -s . foocontinuez cdà foo - /bin/pwdvous direz que vous êtes toujours dans le même répertoire, mais le shell intégré pwddira que vous y êtes /foo/foo/foo/foo/foo/foo- même si aucun répertoire de ce type n'existe vraiment. (Cela dit - vous pouvez probablement cden faire plus.)

Une autre source de confusion existe si les répertoires sont renommés. /bin/pwdLa modification sera immédiatement prise en compte, mais le composant intégré pwdne le sera pas tant que vous n’aurez pas fait quelque chose qui indique que l’ancien nom de répertoire n’a pas d’importance.

— dougmc
source

1

Vous ne répondez pas à la question, vous la rejetez.

— Dmitry Grigoryev

4

Bien que cela ne réponde pas directement à la question , je pense que c'est un article utile pour comprendre la différence entre le shell pwdintégré /bin/pwdet expliquer comment la version autonome fournit des informations plus utiles (qui peuvent répondre à la question initiale).

— Anthony G - justice pour Monica

1

Ces différences se résument toutes à -Pet -Loptions mentionnées par d' autres réponses. En bref, certaines implémentations utilisent par défaut les unes les autres. Sur le système Centos, j’ai besoin de savoir que la commande intégrée de bash est configurée par défaut sur logique et /bin/pwdphysique, mais que les deux options acceptent les deux options de ligne de commande et s’accordent sur le résultat obtenu.

— IMSoP

1

La question est basée sur une prémisse incorrecte - "y at-il un moyen de savoir que je suis" vraiment "dans / var / lib / class? Cela dit ... en expliquant ce que cela signifie réellement, cela l'aide à comprendre ce qu'il recherche vraiment. Les PWD options -P et -L avaient déjà été mentionnés ...

— dougmc

1

Vous avez votre argument à l'envers. ls ..montrera le contenu de /var/lib, pas /home/cpm135/public_html. cd ..est spécial: le shell effectue un suivi spécial de "comment vous y êtes arrivé" et ne fait pas réellement d' chdir("..")appel système. En ce qui concerne le noyau, le répertoire de travail actuel de votre shell ( /proc/self/cwd) est juste un point de montage: une paire d'inodes. C'est comme un descripteur de fichier ouvert sur le répertoire, ce qui explique pourquoi renommer le répertoire ne casse pas votre shell. ( cd .pour mettre à jour la $PWDvariable du shell ). Vous faites valoir un point utile, alors je voterais ceci une fois résolu

— Peter Cordes

1

En gros, vous demandez s’il faut montrer le chemin réel du répertoire de travail en cours. Eh bien, il y a avec python et os.getcwd()fonction

Ce que vous voyez ci-dessous est un petit test situé dans le répertoire "VirtualBox VMs" situé dans mon répertoire personnel. En réalité, il s’agit d’un lien symbolique vers un autre répertoire situé sur un disque dur différent, monté sur /mnt/HDD.

bash-4.3$ file "$(pwd)"
/home/xieerqi/VirtualBox VMs: symbolic link to /mnt/HDD/VirtualBox VMs/
bash-4.3$ python -c 'import os; print os.getcwd()'
/mnt/HDD/VirtualBox VMs

Comme vous pouvez le constater, python os.getcwd()résout le chemin réel du répertoire, pas le chemin du lien symbolique.

— Sergiy Kolodyazhnyy
source