Liaisons logiques et chemins Unix

Je suis un peu confus sur le fonctionnement des liens souples dans unix. Voir l'exempleLiaisons logiques et chemins Unix

% cd /usr/local/ 
% ls -la 
total 6 
drwxr-xr-x 2 root  root   512 Jan 19 15:03 . 
drwxr-xr-x 41 root  sys   1024 Jan 20 16:24 .. 
lrwxrwxrwx 1 root  root   38 Jan 19 15:03 java -> /otherDir/java/jdk1.6.0_17 **<- this is a soft link** 

% cd java **<- move to the softlink** 

% pwd 
/usr/local/java **<- the current location, say LOCATION_A** 

% cd /otherDir/java/jdk1.6.0_17/ **<-move to the location of the softlink** 

% pwd 
/otherDir/java/jdk1.6.0_17 **<- the new current location, say LOCATION_B**

est-ce pas un problème que même si location_a est LOCATION_B, ils ont des chemins différents?

Y at-il une commande (autre que PWD) qui donnera le véritable emplacement d'un fichier (non seulement comment l'utilisateur y aller).

Il me semble que PWD est juste la somme des cd d'un utilisateur. PAS leur emplacement actuel.

Source

2010-01-20 sixtyfootersdude

Ceci se comporte comme ceci avec un but. Si vous cd à /a/b/c/d puis cd à .. alors vous vous attendez à être dans /a/b/c. Si c se trouve être un lien symbolique (ou lien symbolique en termes unix - mais lien pas mou) qui vous amène à /f/g/h, avec le comportement que vous aimeriez avoir vous finiriez dans /f/g et vous (ou tout autre programme) ne comprendre comment cela est arrivé.

Source

2010-01-20 22:41:59

C'est l'hypothèse intégrée dans les shells qui implémentent ce comportement. Ce n'est pas nécessairement l'hypothèse intégrée dans les utilisateurs des coquilles jusqu'à ce qu'ils connaissent le comportement inattendu. Une fois acclimaté, il semble un peu naturel; Je ne suis toujours pas totalement convaincu et ce n'est pas toujours ce que je veux. IIRC, vous pouvez obtenir le comportement naïf avec «cd ./ ..». –

Désolé, il n'est pas clair pour moi ce que votre premier "That" se réfère à. Que penses-tu du comportement du noyau pour les cas '/ a/b/c/..' où 'c' est un lien symbolique vers'/f/g/h/'? Je pense que ce serait '/ a/b /', mais pas sûr. –

Non, le comportement du noyau est que '/ a/b/c/..' est '/ f/g'. Le comportement "intuitif" basé sur votre chemin d'accès est purement une invention shell, et seulement quelques coquilles. Pour autant que je m'en souvienne, 'csh' n'a pas de supercherie et se comporte donc comme le ferait le système nativement. – ephemient

Essayez pwd -P. Ce n'est pas "autre que pwd" mais ça fait l'affaire, au moins sur mon bash 4.0.35 sur Fedora 12. YMMV.

Mise à jour: fonctionne même avec sh, il semble être portable.

Source

2010-01-20 22:41:18

Vous pouvez utiliser readlink sur le répertoire de travail courant pour obtenir le vrai nom du répertoire:

readlink `pwd`

Source

2010-01-20 22:42:31

realpath fait ce que vous voulez.

Source

2010-01-20 22:43:28 ennuikiller

Normalement, pwd devrait retourner /usr/local/java dans la dernière ligne, si je comprends votre exemple. Mais certains shells ont une commande construite enpwd qui essaye d'être plus "intelligente" en gérant les liens symboliques dans le répertoire de travail courant.

Essayez /bin/pwd, obtenez-vous d'autres résultats?

Source

2010-01-20 22:48:46

Il n'est pas possible d'obtenir absolument votre chemin en toutes circonstances. C'est un peu bizarre, mais une variation de ceci (plus chroot et setuid) est parfois utilisée pour verrouiller un processus.

 
$ mkdir -p /tmp/a/b 
$ cd /tmp/a/b 
$ rmdir /tmp/a/b 
$ chmod 0 /tmp/a 
$ rmdir /tmp/a 
$ ls .. 
ls: cannot open directory ..: Permission denied 
$ ls -al 
total 0 
$ pwd -P 
pwd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

Source

2010-01-20 23:45:46 ephemient

Liaisons logiques et chemins Unix

Répondre

Questions connexes