Je cherche le moyen de supprimer tous les liens symboliques pointant
sur des fichiers qui n'existe pas ou plus, dans un syst=E8me.=20
Que conna=EEtriez-vous de bien, en console ou en mode texte, pour les
d=E9busquer =E9ventuellement les lister et enfin, les supprimer ? (Je suis
=E0 l'aise avec la console, sans toutefois savoir =E9crire des scripts
shell)
On m'avait parl=E9 de fslint, mais =E7a ne semble pas destin=E9 =E0
cet usage.
http://www.pixelbeat.org/fslint/
http://fslint.googlecode.com/svn/trunk/doc/FAQ
=AB In summary the algorithm is:
1. exclude files with unique lengths
2. handle files that are hardlinked to each other
3. exclude files with unique md5(first_4k(file))
... =BB
Je cherche le moyen de supprimer tous les liens symboliques pointant sur des fichiers qui n'existe pas ou plus, dans un système.
Que connaîtriez-vous de bien, en console ou en mode texte, pour les débusquer éventuellement les lister
find / -follow -lname * -print
et enfin, les supprimer ?
find / -follow -lname * -exec rm {} ;
Mélodie
On Sun, 23 Aug 2009 02:29:13 +0200 YBM wrote:
> Je cherche le moyen de supprimer tous les liens symboliques pointant > sur des fichiers qui n'existe pas ou plus, dans un système. > > Que connaîtriez-vous de bien, en console ou en mode texte, pour les > débusquer éventuellement les lister
find / -follow -lname * -print
> et enfin, les supprimer ?
find / -follow -lname * -exec rm {} ;
Bonjour,
Merci beaucoup. Pour être sûre, dans lname : le premier caractère est bien un "L" minuscule ? (Remarquez, je vais vérifier le man... ça devrait pouvoir se trouver). :-|
Bonne journée, Mélodie
On Sun, 23 Aug 2009 02:29:13 +0200
YBM <ybmess@nooos.fr> wrote:
> Je cherche le moyen de supprimer tous les liens symboliques pointant
> sur des fichiers qui n'existe pas ou plus, dans un système.
>
> Que connaîtriez-vous de bien, en console ou en mode texte, pour les
> débusquer éventuellement les lister
find / -follow -lname * -print
> et enfin, les supprimer ?
find / -follow -lname * -exec rm {} ;
Bonjour,
Merci beaucoup. Pour être sûre, dans lname : le premier caractère est
bien un "L" minuscule ? (Remarquez, je vais vérifier le man... ça
devrait pouvoir se trouver). :-|
> Je cherche le moyen de supprimer tous les liens symboliques pointant > sur des fichiers qui n'existe pas ou plus, dans un système. > > Que connaîtriez-vous de bien, en console ou en mode texte, pour les > débusquer éventuellement les lister
find / -follow -lname * -print
> et enfin, les supprimer ?
find / -follow -lname * -exec rm {} ;
Bonjour,
Merci beaucoup. Pour être sûre, dans lname : le premier caractère est bien un "L" minuscule ? (Remarquez, je vais vérifier le man... ça devrait pouvoir se trouver). :-|
Bonne journée, Mélodie
Philippe Naudin
On Sun, 23 Aug 2009 02:29:13 +0200 YBM wrote:
Mélodie a écrit : > Bonjour, > > Je cherche le moyen de supprimer tous les liens symboliques pointant > sur des fichiers qui n'existe pas ou plus, dans un système. > > Que connaîtriez-vous de bien, en console ou en mode texte, pour les > débusquer éventuellement les lister
find / -follow -lname * -print
Pas terrible comme solution : $ find . -follow -ilname * me crache des milliers de lignes du style : find: Le lien symbolique `./.wine/dosdevices/z:/dev/.udev/failed/ i0000::00:1e.0/bus/devices/0000:02:0a.0/sound:pcmC0D0p/subsystem/aud io/subsystem' fait parti d'une boucle dans la hiérarchie du répertoire; le répertoire sur lequel il pointe a déjà été visité.
On peut améliorer en ajoutant -xdev (il y a des effets secondaires), mais ça va quand même cafouiller avec les références circulaires.
En nettoyant la sortie, ça se présente mieux : $ LC_MESSAGES=C find . -follow -ilname * 2>&1 | grep -v 'loop in the directory hierarchy|Filesystem loop detected' mais il y a probablement d'autres possibilités d'erreurs auxquelles je ne pense pas. Et il faut quand même -xdev si on risque de trouver des liens vers /dev ou des montages NFS par exemple, surtout si on joue avec "-exec rm {}" :))
Une méthode plus sélective a déjà été proposée ici (ou bien s ur fcou, je ne me souviens plus) : $ LC_MESSAGES=C find . -type l -exec ls -L {} ; 2>&1 | grep "No such file" | sed -e 's/: No such file.*// ; s/^ls: //'
Cordialement,
-- Philippe
On Sun, 23 Aug 2009 02:29:13 +0200
YBM <ybmess@nooos.fr> wrote:
Mélodie a écrit :
> Bonjour,
>
> Je cherche le moyen de supprimer tous les liens symboliques pointant
> sur des fichiers qui n'existe pas ou plus, dans un système.
>
> Que connaîtriez-vous de bien, en console ou en mode texte, pour les
> débusquer éventuellement les lister
find / -follow -lname * -print
Pas terrible comme solution :
$ find . -follow -ilname *
me crache des milliers de lignes du style :
find: Le lien symbolique `./.wine/dosdevices/z:/dev/.udev/failed/devices@pc i0000:00@0000:00:1e.0/bus/devices/0000:02:0a.0/sound:pcmC0D0p/subsystem/aud io/subsystem' fait parti d'une boucle dans la hiérarchie du répertoire; le répertoire sur lequel il pointe a déjà été visité.
On peut améliorer en ajoutant -xdev (il y a des effets secondaires),
mais ça va quand même cafouiller avec les références circulaires.
En nettoyant la sortie, ça se présente mieux :
$ LC_MESSAGES=C find . -follow -ilname * 2>&1 |
grep -v 'loop in the directory hierarchy|Filesystem loop detected'
mais il y a probablement d'autres possibilités d'erreurs auxquelles je
ne pense pas.
Et il faut quand même -xdev si on risque de trouver des liens vers /dev
ou des montages NFS par exemple, surtout si on joue avec "-exec rm {}"
:))
Une méthode plus sélective a déjà été proposée ici (ou bien s ur fcou,
je ne me souviens plus) :
$ LC_MESSAGES=C find . -type l -exec ls -L {} ; 2>&1 |
grep "No such file" |
sed -e 's/: No such file.*// ; s/^ls: //'
Mélodie a écrit : > Bonjour, > > Je cherche le moyen de supprimer tous les liens symboliques pointant > sur des fichiers qui n'existe pas ou plus, dans un système. > > Que connaîtriez-vous de bien, en console ou en mode texte, pour les > débusquer éventuellement les lister
find / -follow -lname * -print
Pas terrible comme solution : $ find . -follow -ilname * me crache des milliers de lignes du style : find: Le lien symbolique `./.wine/dosdevices/z:/dev/.udev/failed/ i0000::00:1e.0/bus/devices/0000:02:0a.0/sound:pcmC0D0p/subsystem/aud io/subsystem' fait parti d'une boucle dans la hiérarchie du répertoire; le répertoire sur lequel il pointe a déjà été visité.
On peut améliorer en ajoutant -xdev (il y a des effets secondaires), mais ça va quand même cafouiller avec les références circulaires.
En nettoyant la sortie, ça se présente mieux : $ LC_MESSAGES=C find . -follow -ilname * 2>&1 | grep -v 'loop in the directory hierarchy|Filesystem loop detected' mais il y a probablement d'autres possibilités d'erreurs auxquelles je ne pense pas. Et il faut quand même -xdev si on risque de trouver des liens vers /dev ou des montages NFS par exemple, surtout si on joue avec "-exec rm {}" :))
Une méthode plus sélective a déjà été proposée ici (ou bien s ur fcou, je ne me souviens plus) : $ LC_MESSAGES=C find . -type l -exec ls -L {} ; 2>&1 | grep "No such file" | sed -e 's/: No such file.*// ; s/^ls: //'
Cordialement,
-- Philippe
Nicolas George
Philippe Naudin wrote in message :
En nettoyant la sortie, ça se présente mieux : $ LC_MESSAGES=C find . -follow -ilname * 2>&1 | grep -v 'loop in the directory hierarchy|Filesystem loop detected' mais il y a probablement d'autres possibilités d'erreurs auxquelles je ne pense pas.
Ce sont des erreurs, donc elles sont affichées sur la sortie d'erreur, donc elles ne gênent pas les résultats fournis par la commande.
Une méthode plus sélective a déjà été proposée ici (ou bien sur fcou, je ne me souviens plus) : $ LC_MESSAGES=C find . -type l -exec ls -L {} ; 2>&1 | grep "No such file" | sed -e 's/: No such file.*// ; s/^ls: //'
Cette commande (1) parse la sortie de ls, (2) contient le texte d'un message d'erreur et (3) lit la sortie d'erreur d'un programme. Chacun de ces trois éléments est à lui seul le signe que cette commande est fondamentalement buggée.
La commande avec find -follow devrait marcher avec un peu d'amélioration, mais le prédicat -follow ne fait pas exactement ce qu'on veut, donc ça ne marche pas. On peut faire avec la même méthode avec des langages qui ont un prédicat équivalent à -follow défini correctement.
Avec zsh :
ls **/*(@-@)
(avec n'importe quoi à la place de ls)
Avec perl :
perl -MFile::Find -e 'find sub { -l && !-e && print $File::Find::name, "n" }, "."'
(ou à la place de n, bien sûr)
Attention, dans certains répertoires du système, la présence de liens orphelins est normale.
Philippe Naudin wrote in message
<20090823104350.0601f005@PEINARD.chezmoi>:
En nettoyant la sortie, ça se présente mieux :
$ LC_MESSAGES=C find . -follow -ilname * 2>&1 |
grep -v 'loop in the directory hierarchy|Filesystem loop detected'
mais il y a probablement d'autres possibilités d'erreurs auxquelles je
ne pense pas.
Ce sont des erreurs, donc elles sont affichées sur la sortie d'erreur, donc
elles ne gênent pas les résultats fournis par la commande.
Une méthode plus sélective a déjà été proposée ici (ou bien sur fcou,
je ne me souviens plus) :
$ LC_MESSAGES=C find . -type l -exec ls -L {} ; 2>&1 |
grep "No such file" |
sed -e 's/: No such file.*// ; s/^ls: //'
Cette commande (1) parse la sortie de ls, (2) contient le texte d'un message
d'erreur et (3) lit la sortie d'erreur d'un programme. Chacun de ces trois
éléments est à lui seul le signe que cette commande est fondamentalement
buggée.
La commande avec find -follow devrait marcher avec un peu d'amélioration,
mais le prédicat -follow ne fait pas exactement ce qu'on veut, donc ça ne
marche pas. On peut faire avec la même méthode avec des langages qui ont un
prédicat équivalent à -follow défini correctement.
Avec zsh :
ls **/*(@-@)
(avec n'importe quoi à la place de ls)
Avec perl :
perl -MFile::Find -e
'find sub { -l && !-e && print $File::Find::name, "n" }, "."'
(ou à la place de n, bien sûr)
Attention, dans certains répertoires du système, la présence de liens
orphelins est normale.
En nettoyant la sortie, ça se présente mieux : $ LC_MESSAGES=C find . -follow -ilname * 2>&1 | grep -v 'loop in the directory hierarchy|Filesystem loop detected' mais il y a probablement d'autres possibilités d'erreurs auxquelles je ne pense pas.
Ce sont des erreurs, donc elles sont affichées sur la sortie d'erreur, donc elles ne gênent pas les résultats fournis par la commande.
Une méthode plus sélective a déjà été proposée ici (ou bien sur fcou, je ne me souviens plus) : $ LC_MESSAGES=C find . -type l -exec ls -L {} ; 2>&1 | grep "No such file" | sed -e 's/: No such file.*// ; s/^ls: //'
Cette commande (1) parse la sortie de ls, (2) contient le texte d'un message d'erreur et (3) lit la sortie d'erreur d'un programme. Chacun de ces trois éléments est à lui seul le signe que cette commande est fondamentalement buggée.
La commande avec find -follow devrait marcher avec un peu d'amélioration, mais le prédicat -follow ne fait pas exactement ce qu'on veut, donc ça ne marche pas. On peut faire avec la même méthode avec des langages qui ont un prédicat équivalent à -follow défini correctement.
Avec zsh :
ls **/*(@-@)
(avec n'importe quoi à la place de ls)
Avec perl :
perl -MFile::Find -e 'find sub { -l && !-e && print $File::Find::name, "n" }, "."'
(ou à la place de n, bien sûr)
Attention, dans certains répertoires du système, la présence de liens orphelins est normale.
YBM
Nicolas George a écrit :
La commande avec find -follow devrait marcher avec un peu d'amélioration, mais le prédicat -follow ne fait pas exactement ce qu'on veut,
Il fait exactement ce que l'on veut lorsque lname est invoqué.
-lname pattern File is a symbolic link whose contents match shell pattern pat‐ tern. The metacharacters do not treat ‘/’ or ‘.’ specially. If the -L option or the -follow option is in effect, this test returns false unless the symbolic link is broken.
Nicolas George a écrit :
La commande avec find -follow devrait marcher avec un peu d'amélioration,
mais le prédicat -follow ne fait pas exactement ce qu'on veut,
Il fait exactement ce que l'on veut lorsque lname est invoqué.
-lname pattern
File is a symbolic link whose contents match shell pattern pat‐
tern. The metacharacters do not treat ‘/’ or ‘.’ specially. If
the -L option or the -follow option is in effect, this test
returns false unless the symbolic link is broken.
La commande avec find -follow devrait marcher avec un peu d'amélioration, mais le prédicat -follow ne fait pas exactement ce qu'on veut,
Il fait exactement ce que l'on veut lorsque lname est invoqué.
-lname pattern File is a symbolic link whose contents match shell pattern pat‐ tern. The metacharacters do not treat ‘/’ or ‘.’ specially. If the -L option or the -follow option is in effect, this test returns false unless the symbolic link is broken.
Nicolas George
YBM wrote in message <4a9114a1$0$7768$:
Il fait exactement ce que l'on veut lorsque lname est invoqué.
Non. Ce serait vrai si c'était son seul effet, mais ce n'est pas le cas : il a d'autres conséquences, qui sont mal documentées et mal conçues. L'existence des messages d'erreur signalant des boucles en est la preuve.
YBM wrote in message <4a9114a1$0$7768$426a74cc@news.free.fr>:
Il fait exactement ce que l'on veut lorsque lname est invoqué.
Non. Ce serait vrai si c'était son seul effet, mais ce n'est pas le cas : il
a d'autres conséquences, qui sont mal documentées et mal conçues.
L'existence des messages d'erreur signalant des boucles en est la preuve.
Il fait exactement ce que l'on veut lorsque lname est invoqué.
Non. Ce serait vrai si c'était son seul effet, mais ce n'est pas le cas : il a d'autres conséquences, qui sont mal documentées et mal conçues. L'existence des messages d'erreur signalant des boucles en est la preuve.
YBM
Nicolas George a écrit :
YBM wrote in message <4a9114a1$0$7768$:
Il fait exactement ce que l'on veut lorsque lname est invoqué.
Non. Ce serait vrai si c'était son seul effet, mais ce n'est pas le cas : il a d'autres conséquences, qui sont mal documentées et mal conçues. L'existence des messages d'erreur signalant des boucles en est la preuve.
Rien à voir, n'importe quelle recherche avec find, -follow ou pas, signale les boucles.
Nicolas George a écrit :
YBM wrote in message <4a9114a1$0$7768$426a74cc@news.free.fr>:
Il fait exactement ce que l'on veut lorsque lname est invoqué.
Non. Ce serait vrai si c'était son seul effet, mais ce n'est pas le cas : il
a d'autres conséquences, qui sont mal documentées et mal conçues.
L'existence des messages d'erreur signalant des boucles en est la preuve.
Rien à voir, n'importe quelle recherche avec find, -follow ou pas,
signale les boucles.
Il fait exactement ce que l'on veut lorsque lname est invoqué.
Non. Ce serait vrai si c'était son seul effet, mais ce n'est pas le cas : il a d'autres conséquences, qui sont mal documentées et mal conçues. L'existence des messages d'erreur signalant des boucles en est la preuve.
Rien à voir, n'importe quelle recherche avec find, -follow ou pas, signale les boucles.
Nicolas George
YBM wrote in message <4a911a94$0$25139$:
Rien à voir, n'importe quelle recherche avec find, -follow ou pas, signale les boucles.
Non, c'est faux. Fais l'essai si tu ne me crois pas. Sans -follow ou -L, find traite les liens symboliques exactement comme il traite les fichiers réguliers, les devices, les fifos, les sockets, etc. : il les affiche, mais ne descend pas dedans comme il le fait avec les répertoires.
Une boucle ne peut donc pas arriver, à moins d'avoir un lien dur sur un répertoire, ce qui n'est normalement pas permis, ou un montage lié, ce qui est rare.
YBM wrote in message <4a911a94$0$25139$426a74cc@news.free.fr>:
Rien à voir, n'importe quelle recherche avec find, -follow ou pas,
signale les boucles.
Non, c'est faux. Fais l'essai si tu ne me crois pas. Sans -follow ou -L,
find traite les liens symboliques exactement comme il traite les fichiers
réguliers, les devices, les fifos, les sockets, etc. : il les affiche, mais
ne descend pas dedans comme il le fait avec les répertoires.
Une boucle ne peut donc pas arriver, à moins d'avoir un lien dur sur un
répertoire, ce qui n'est normalement pas permis, ou un montage lié, ce qui
est rare.
Rien à voir, n'importe quelle recherche avec find, -follow ou pas, signale les boucles.
Non, c'est faux. Fais l'essai si tu ne me crois pas. Sans -follow ou -L, find traite les liens symboliques exactement comme il traite les fichiers réguliers, les devices, les fifos, les sockets, etc. : il les affiche, mais ne descend pas dedans comme il le fait avec les répertoires.
Une boucle ne peut donc pas arriver, à moins d'avoir un lien dur sur un répertoire, ce qui n'est normalement pas permis, ou un montage lié, ce qui est rare.
Philippe Naudin
On 23 Aug 2009 09:15:18 GMT Nicolas George <nicolas$ wrote:
Philippe Naudin wrote in message : > En nettoyant la sortie, ça se présente mieux : > $ LC_MESSAGES=C find . -follow -ilname * 2>&1 | > grep -v 'loop in the directory hierarchy|Filesystem loop detected' > mais il y a probablement d'autres possibilités d'erreurs auxquelles j e > ne pense pas.
Ce sont des erreurs, donc elles sont affichées sur la sortie d'erreur, donc elles ne gênent pas les résultats fournis par la commande.
Rhââa zut : tout à fait exact ! Je m'étais focalisé sur le fait q ue -follow risque d'envoyer dans les choux, mais c'est sûr que 2>/dev/null est quand même bien plus efficace pour ce qui est de nettoyer la sortie.
La commande avec find -follow devrait marcher avec un peu d'amélioratio n, mais le prédicat -follow ne fait pas exactement ce qu'on veut, donc ç a ne marche pas. On peut faire avec la même méthode avec des langages qui ont un prédicat équivalent à -follow défini correctement.
Avec zsh :
ls **/*(@-@)
Il manque les fichiers/répertoires cachés, non ?
Avec perl :
perl -MFile::Find -e 'find sub { -l && !-e && print $File::Find::name, "n" }, "."' (ou à la place de n, bien sûr)
Bien vu !
Attention, dans certains répertoires du système, la présence de lie ns orphelins est normale.
C'est pour ça qu'il faut se méfier de find -follow. Si tous les liens orphelins étaient bons pour la poubelle, il n'y aurait pas de souci.
Cordialement,
-- Philippe
On 23 Aug 2009 09:15:18 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
Philippe Naudin wrote in message
<20090823104350.0601f005@PEINARD.chezmoi>:
> En nettoyant la sortie, ça se présente mieux :
> $ LC_MESSAGES=C find . -follow -ilname * 2>&1 |
> grep -v 'loop in the directory hierarchy|Filesystem loop detected'
> mais il y a probablement d'autres possibilités d'erreurs auxquelles j e
> ne pense pas.
Ce sont des erreurs, donc elles sont affichées sur la sortie d'erreur, donc
elles ne gênent pas les résultats fournis par la commande.
Rhââa zut : tout à fait exact ! Je m'étais focalisé sur le fait q ue
-follow risque d'envoyer dans les choux, mais c'est sûr que 2>/dev/null
est quand même bien plus efficace pour ce qui est de nettoyer la sortie.
La commande avec find -follow devrait marcher avec un peu d'amélioratio n,
mais le prédicat -follow ne fait pas exactement ce qu'on veut, donc ç a ne
marche pas. On peut faire avec la même méthode avec des langages qui ont un
prédicat équivalent à -follow défini correctement.
Avec zsh :
ls **/*(@-@)
Il manque les fichiers/répertoires cachés, non ?
Avec perl :
perl -MFile::Find -e
'find sub { -l && !-e && print $File::Find::name, "n" }, "."'
(ou à la place de n, bien sûr)
Bien vu !
Attention, dans certains répertoires du système, la présence de lie ns
orphelins est normale.
C'est pour ça qu'il faut se méfier de find -follow. Si tous les liens
orphelins étaient bons pour la poubelle, il n'y aurait pas de souci.
On 23 Aug 2009 09:15:18 GMT Nicolas George <nicolas$ wrote:
Philippe Naudin wrote in message : > En nettoyant la sortie, ça se présente mieux : > $ LC_MESSAGES=C find . -follow -ilname * 2>&1 | > grep -v 'loop in the directory hierarchy|Filesystem loop detected' > mais il y a probablement d'autres possibilités d'erreurs auxquelles j e > ne pense pas.
Ce sont des erreurs, donc elles sont affichées sur la sortie d'erreur, donc elles ne gênent pas les résultats fournis par la commande.
Rhââa zut : tout à fait exact ! Je m'étais focalisé sur le fait q ue -follow risque d'envoyer dans les choux, mais c'est sûr que 2>/dev/null est quand même bien plus efficace pour ce qui est de nettoyer la sortie.
La commande avec find -follow devrait marcher avec un peu d'amélioratio n, mais le prédicat -follow ne fait pas exactement ce qu'on veut, donc ç a ne marche pas. On peut faire avec la même méthode avec des langages qui ont un prédicat équivalent à -follow défini correctement.
Avec zsh :
ls **/*(@-@)
Il manque les fichiers/répertoires cachés, non ?
Avec perl :
perl -MFile::Find -e 'find sub { -l && !-e && print $File::Find::name, "n" }, "."' (ou à la place de n, bien sûr)
Bien vu !
Attention, dans certains répertoires du système, la présence de lie ns orphelins est normale.
C'est pour ça qu'il faut se méfier de find -follow. Si tous les liens orphelins étaient bons pour la poubelle, il n'y aurait pas de souci.
Cordialement,
-- Philippe
YBM
Nicolas George a écrit :
YBM wrote in message <4a911a94$0$25139$:
Rien à voir, n'importe quelle recherche avec find, -follow ou pas, signale les boucles.
Non, c'est faux. Fais l'essai si tu ne me crois pas. Sans -follow ou -L, find traite les liens symboliques exactement comme il traite les fichiers réguliers, les devices, les fifos, les sockets, etc. : il les affiche, mais ne descend pas dedans comme il le fait avec les répertoires.
Vu. Ceci dit il reste que find se contente de les signaler, et ne les considère pas comme des liens orphelins.
Il est quand même assez malin le GNU find, il considère qu'un lien symbolique vers un lien symbolique orphelin est lui même orphelin :
$ find . -follow -lname * -print 2> /dev/null ./toto ./tyty $ file tyty toto tyty: broken symbolic link to `toto' toto: broken symbolic link to `titi'
Bref il répond au cahier des charges, ce d'autant mieux que l'admin aura pris soin de lui faire éviter les systèmes de fichiers spéciaux :
find / -xdev ... puis find /home ... find /usr ... etc.
Nicolas George a écrit :
YBM wrote in message <4a911a94$0$25139$426a74cc@news.free.fr>:
Rien à voir, n'importe quelle recherche avec find, -follow ou pas,
signale les boucles.
Non, c'est faux. Fais l'essai si tu ne me crois pas. Sans -follow ou -L,
find traite les liens symboliques exactement comme il traite les fichiers
réguliers, les devices, les fifos, les sockets, etc. : il les affiche, mais
ne descend pas dedans comme il le fait avec les répertoires.
Vu. Ceci dit il reste que find se contente de les signaler, et ne les
considère pas comme des liens orphelins.
Il est quand même assez malin le GNU find, il considère qu'un lien
symbolique vers un lien symbolique orphelin est lui même orphelin :
$ find . -follow -lname * -print 2> /dev/null
./toto
./tyty
$ file tyty toto
tyty: broken symbolic link to `toto'
toto: broken symbolic link to `titi'
Bref il répond au cahier des charges, ce d'autant mieux que l'admin
aura pris soin de lui faire éviter les systèmes de fichiers spéciaux :
find / -xdev ...
puis
find /home ...
find /usr ...
etc.
Rien à voir, n'importe quelle recherche avec find, -follow ou pas, signale les boucles.
Non, c'est faux. Fais l'essai si tu ne me crois pas. Sans -follow ou -L, find traite les liens symboliques exactement comme il traite les fichiers réguliers, les devices, les fifos, les sockets, etc. : il les affiche, mais ne descend pas dedans comme il le fait avec les répertoires.
Vu. Ceci dit il reste que find se contente de les signaler, et ne les considère pas comme des liens orphelins.
Il est quand même assez malin le GNU find, il considère qu'un lien symbolique vers un lien symbolique orphelin est lui même orphelin :
$ find . -follow -lname * -print 2> /dev/null ./toto ./tyty $ file tyty toto tyty: broken symbolic link to `toto' toto: broken symbolic link to `titi'
Bref il répond au cahier des charges, ce d'autant mieux que l'admin aura pris soin de lui faire éviter les systèmes de fichiers spéciaux :
find / -xdev ... puis find /home ... find /usr ... etc.
