trouver une utilisation avec -L


34

j'ai

link -> file

je fais

find -L . -name 'link'

Et obtenir

./link

Pourquoi donc?

l'homme trouve dit:

-L: Suivre les liens symboliques. Lorsque find examine ou imprime des informations sur les fichiers, les informations utilisées doivent être extraites des propriétés du fichier vers lequel pointe le lien, et non du lien lui-même (à moins qu'il s'agisse d'un lien symbolique rompu ou que find ne puisse pas examiner le fichier. vers lequel le lien pointe).

Réponses:


12

Avec -L, il examine les propriétés du fichier - le contenu ou les métadonnées, pas celles du lien. Par exemple, si vous utilisez -atime, il vérifiera atimele fichier, pas le lien:

$ find testdir/ -name link -newer testdir/ref
testdir/link
$ find -L testdir/ -name link -newer testdir/ref
$

testdir/linka été créé après testdir/ref, mais le fichier indiqué ne l’était pas.


1
Pouvez-vous expliquer en prenant mon exemple? Ce que je comprends, c’est ceci: Dans mon exemple, find commence sa recherche. Il rencontre ./link, puisque -L est en fait il le déréférence et prend les propriétés de ./file. Il compare le nom du fichier ./file avec le modèle 'link' et, comme il ne correspond pas, ne doit pas signaler de 0 / p. Quel est le problème avec mon raisonnement?
Ankur Agarwal

Dans le manuel de recherche que vous avez cité, "les informations utilisées doivent être extraites des propriétés du fichier sur lequel pointe le lien". Le nom d'un fichier ne fait pas partie de ses propriétés. Il utilise donc toujours le nom du lien. C'est aussi beaucoup plus utile que le nom du fichier réel.
Kevin

"Le nom du fichier ne fait pas partie de ses propriétés" Je ne le savais pas. Ces autres attributs de fichiers qui ne sont pas considérés comme des propriétés? Pour être honnête, je suis toujours sceptique et j'attendrais ce que les autres ont à dire.
Ankur Agarwal

Identique à @abc, je ne savais pas qu'un nom de fichier n'était pas une propriété de fichier. Où puis-je trouver cette information dans une documentation et / ou des pages de manuel? Veuillez vous reporter à l'endroit où je peux en apprendre davantage sur les propriétés d'un fichier.
Joker

34

La règle générale est que si une commande fonctionne sur des liens (c’est-à-dire des entrées de répertoire qui sont des pointeurs d’inodes), elle traite alors les liens symboliques comme tels, plutôt que comme l’objet vers lequel le lien pointe. Sinon, la commande agit sur ce que le lien symbolique pointe vers. Ainsi cpsuit les liens symboliques par défaut et copie le contenu du fichier pointé par le lien. Mais lorsque vous demandez cpde traiter les entrées du répertoire en spécifiant -R, il ne suit plus les liens symboliques. mvfonctionne toujours avec les entrées de répertoire, et ne suit donc jamais les liens symboliques.

L' findactivité normale de la commande est d'opérer sur les entrées de l'annuaire, les liens symboliques ne sont donc pas suivis par défaut. L'ajout de -Lcauses findà suivre les liens symboliques pour toutes les propriétés, à l' exception de celle qui ne peut être ignorée lors de la recherche dans le répertoire, est le nom. L'un des objectifs de find -nameest de fournir une entrée pour des commandes telles que mvet rmqui agissent sur les entrées de répertoire. Il y aurait des résultats désagréables et surprenants si vous find -L dir -namepouviez produire des noms pointant hors de l'arborescence de répertoires sur laquelle est enraciné dir.


HOU LA LA! Pourquoi ce concept subtil n'est-il pas bien illustré sur les pages de manuel (à moins que je ne l'aie pas manqué)? C'est une grosse surprise pour moi.
Ankur Agarwal

2
@Kyle Jones There would be unpleasant and surprising results if trouver -L dir -nom` pourrait produire des noms pointant hors de l'arborescence de répertoires dont le répertoire racine est dir.` => ne devrait-il pas en être autrement: il y aurait désagréable ... si find dir -name pattern...? parce que l'ajout de -L permet de pointer vers un
répertoire

Alors, comment faire cp -Rpour copier des choses sous un lien symbolique?
javadba
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.