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
S'il y a un lien quelque part vers la racine, il explorera toute l'arborescence à partir de ce lien. Ça peut être particulièrement dangereux si on a lancé find depuis un répertoire pour ne faire le ménage que dans ce répertoire-là.
L'option -xdev n'est pas une protection fiable : elle marchera pour un lien de /home vers / si les deux sont sur des partitions différentes, mais elle ne protégera pas contre un lien de /home/truc vers /home/machin.
Les deux commandes que j'ai postées (perl et zsh) n'ont aucun de ces problèmes.
YBM wrote in message <4a9127be$0$10854$426a74cc@news.free.fr>:
Vu. Ceci dit il reste que find se contente de les signaler, et ne les
considère pas comme des liens orphelins.
Encore heureux. Mais avec follow, il descend potentiellement plusieurs fois
dans chaque répertoire :
S'il y a un lien quelque part vers la racine, il explorera toute
l'arborescence à partir de ce lien. Ça peut être particulièrement dangereux
si on a lancé find depuis un répertoire pour ne faire le ménage que dans ce
répertoire-là.
L'option -xdev n'est pas une protection fiable : elle marchera pour un lien
de /home vers / si les deux sont sur des partitions différentes, mais elle
ne protégera pas contre un lien de /home/truc vers /home/machin.
Les deux commandes que j'ai postées (perl et zsh) n'ont aucun de ces
problèmes.
S'il y a un lien quelque part vers la racine, il explorera toute l'arborescence à partir de ce lien. Ça peut être particulièrement dangereux si on a lancé find depuis un répertoire pour ne faire le ménage que dans ce répertoire-là.
L'option -xdev n'est pas une protection fiable : elle marchera pour un lien de /home vers / si les deux sont sur des partitions différentes, mais elle ne protégera pas contre un lien de /home/truc vers /home/machin.
Les deux commandes que j'ai postées (perl et zsh) n'ont aucun de ces problèmes.
Nicolas George
Philippe Naudin wrote in message :
ls **/*(@-@)
Il manque les fichiers/répertoires cachés, non ?
C'est vrai. **/*(@) devrait donc faire l'affaire.
Philippe Naudin wrote in message
<20090823125444.4e0c75b8@PEINARD.chezmoi>:
ls **/*(@-@)
Il manque les fichiers/répertoires cachés, non ?
C'est vrai. **/*(D@-@) devrait donc faire l'affaire.
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 > 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 bi en 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étho de 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 lie ns orphelins est normale.
Bonjour,
J'ai suivi jusqu'à ce post: From: YBM Date: Sun, 23 Aug 2009 12:02:53 +0200
Je suis bien loin d'être aussi calée que les personnes qui m'ont répondu, alors j'ai quelques questions. Pour la commande zsh, je ne pense pas l'employer sur ce projet, car perl est installé (majoritairement utilisé) dans la machine où je voudrais faire cette opération, aussi, si ça peut faire l'affaire, ça me semble plus judicieux. La raison en est que je veux faire ça dans un système que je souhaite améliorer pour générer une nouvelle version pouvant être installée. (Des remasters de PCLinuxOS, un fork de Mandriva)
Je suis aussi intéressée d'en savoir plus, pour la distribution que j'utilise au quotidien, (Archlinux) un peu de ménage (si ça peut se faire sans endommager le système) me semble toujours une bonne chose. Aussi je m'intéresserais éventuellement à votre suggestion de commande zhs, dans un deuxième temps.
Mes questions pour l'instant sont celles-ci : dans la commande perl (je n'ai aucune connaissance en programmation) quelle différence cela produit, entre ' ' et 'n' ? de quels types d'arguments (ai-je deviné ? est-ce que ce sont bien des arguments ?)
Cette commande ne fait-elle que les rechercher et les afficher ?
À la lumière de quels critères peut-on savoir que la présence de li ens orphelins placés ici où là est normale ? (Et doivent donc être conservés ? Sous peine d'endommager le système ?)
Si j'emploie une commande perl telle que celle ci-dessus, qu'est-ce qui y manquerait pour rediriger la sortie vers un fichier texte ? (Par exemple, 'symlnk_orphelins.txt' )
Merci, Mélodie
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
> 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 bi en 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étho de
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 lie ns
orphelins est normale.
Bonjour,
J'ai suivi jusqu'à ce post:
From: YBM <ybmess@nooos.fr>
Date: Sun, 23 Aug 2009 12:02:53 +0200
Je suis bien loin d'être aussi calée que les personnes qui m'ont
répondu, alors j'ai quelques questions. Pour la commande zsh, je ne
pense pas l'employer sur ce projet, car perl est installé
(majoritairement utilisé) dans la machine où je voudrais faire cette
opération, aussi, si ça peut faire l'affaire, ça me semble plus
judicieux. La raison en est que je veux faire ça dans un système que je
souhaite améliorer pour générer une nouvelle version pouvant être
installée. (Des remasters de PCLinuxOS, un fork de Mandriva)
Je suis aussi intéressée d'en savoir plus, pour la distribution que
j'utilise au quotidien, (Archlinux) un peu de ménage (si ça peut se
faire sans endommager le système) me semble toujours une bonne chose.
Aussi je m'intéresserais éventuellement à votre suggestion de commande
zhs, dans un deuxième temps.
Mes questions pour l'instant sont celles-ci : dans la commande perl (je
n'ai aucune connaissance en programmation) quelle différence cela
produit, entre ' ' et 'n' ? de quels types d'arguments (ai-je
deviné ? est-ce que ce sont bien des arguments ?)
Cette commande ne fait-elle que les rechercher et les afficher ?
À la lumière de quels critères peut-on savoir que la présence de li ens
orphelins placés ici où là est normale ? (Et doivent donc être
conservés ? Sous peine d'endommager le système ?)
Si j'emploie une commande perl telle que celle ci-dessus, qu'est-ce qui
y manquerait pour rediriger la sortie vers un fichier texte ? (Par
exemple, 'symlnk_orphelins.txt' )
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 > 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 bi en 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étho de 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 lie ns orphelins est normale.
Bonjour,
J'ai suivi jusqu'à ce post: From: YBM Date: Sun, 23 Aug 2009 12:02:53 +0200
Je suis bien loin d'être aussi calée que les personnes qui m'ont répondu, alors j'ai quelques questions. Pour la commande zsh, je ne pense pas l'employer sur ce projet, car perl est installé (majoritairement utilisé) dans la machine où je voudrais faire cette opération, aussi, si ça peut faire l'affaire, ça me semble plus judicieux. La raison en est que je veux faire ça dans un système que je souhaite améliorer pour générer une nouvelle version pouvant être installée. (Des remasters de PCLinuxOS, un fork de Mandriva)
Je suis aussi intéressée d'en savoir plus, pour la distribution que j'utilise au quotidien, (Archlinux) un peu de ménage (si ça peut se faire sans endommager le système) me semble toujours une bonne chose. Aussi je m'intéresserais éventuellement à votre suggestion de commande zhs, dans un deuxième temps.
Mes questions pour l'instant sont celles-ci : dans la commande perl (je n'ai aucune connaissance en programmation) quelle différence cela produit, entre ' ' et 'n' ? de quels types d'arguments (ai-je deviné ? est-ce que ce sont bien des arguments ?)
Cette commande ne fait-elle que les rechercher et les afficher ?
À la lumière de quels critères peut-on savoir que la présence de li ens orphelins placés ici où là est normale ? (Et doivent donc être conservés ? Sous peine d'endommager le système ?)
Si j'emploie une commande perl telle que celle ci-dessus, qu'est-ce qui y manquerait pour rediriger la sortie vers un fichier texte ? (Par exemple, 'symlnk_orphelins.txt' )
Merci, Mélodie
Mélodie
On Sun, 23 Aug 2009 15:33:41 +0200 Mélodie wrote:
Aussi je m'intéresserais éventuellement à votre suggestion de comma nde zhs, dans un deuxième temps.
Errata: zsh
(Désolée)
Merci encore, Mélodie
On Sun, 23 Aug 2009 15:33:41 +0200
Mélodie <melodie@nospam.eu> wrote:
Aussi je m'intéresserais éventuellement à votre suggestion de comma nde
zhs, dans un deuxième temps.
Aussi je m'intéresserais éventuellement à votre suggestion de comma nde zhs, dans un deuxième temps.
Errata: zsh
(Désolée)
Merci encore, Mélodie
Nicolas George
Mélodie wrote in message :
Mes questions pour l'instant sont celles-ci : dans la commande perl (je n'ai aucune connaissance en programmation) quelle différence cela produit, entre ' ' et 'n' ?
Le caractère n (retour à la ligne) peut apparaître dans un nom de fichier, pas le caractère nul . Regarde les options -print0 de find et -0 de xargs.
Cette commande ne fait-elle que les rechercher et les afficher ?
« print »
À la lumière de quels critères peut-on savoir que la présence de liens orphelins placés ici où là est normale ?
Si tu ne sais pas, n'y touche pas.
Mélodie wrote in message <20090823153341.d5f84bd1.melodie@nospam.eu>:
Mes questions pour l'instant sont celles-ci : dans la commande perl (je
n'ai aucune connaissance en programmation) quelle différence cela
produit, entre ' ' et 'n' ?
Le caractère n (retour à la ligne) peut apparaître dans un nom de fichier,
pas le caractère nul . Regarde les options -print0 de find et -0 de xargs.
Cette commande ne fait-elle que les rechercher et les afficher ?
« print »
À la lumière de quels critères peut-on savoir que la présence de liens
orphelins placés ici où là est normale ?
Mes questions pour l'instant sont celles-ci : dans la commande perl (je n'ai aucune connaissance en programmation) quelle différence cela produit, entre ' ' et 'n' ?
Le caractère n (retour à la ligne) peut apparaître dans un nom de fichier, pas le caractère nul . Regarde les options -print0 de find et -0 de xargs.
Cette commande ne fait-elle que les rechercher et les afficher ?
« print »
À la lumière de quels critères peut-on savoir que la présence de liens orphelins placés ici où là est normale ?
Si tu ne sais pas, n'y touche pas.
Mélodie
On 23 Aug 2009 14:07:52 GMT Nicolas George <nicolas$ wrote:
Le caractère n (retour à la ligne) peut apparaître dans un nom de fichier, pas le caractère nul . Regarde les options -print0 de find et -0 de xargs.
D'accord, je regarderai.
> Cette commande ne fait-elle que les rechercher et les afficher ?
« print »
Ok.
> À la lumière de quels critères peut-on savoir que la présence de > liens orphelins placés ici où là est normale ?
Si tu ne sais pas, n'y touche pas.
Entendu. Je commencerai par produire une liste à partir de la ligne de commande perl, et la posterai sur le forum de la distribution pour voir quelles informations complémentaires je peux recueillir.
Que faudrait-il de plus dans cette commande pour envoyer la sortie dans un fichier texte ? Dans bash je connais «
/chemin/vers/repertoire/un_fichier.txt », et dans perl, qu'est-ce qui
serait équivalent ?
Merci. :-)
On 23 Aug 2009 14:07:52 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
Le caractère n (retour à la ligne) peut apparaître dans un nom de
fichier, pas le caractère nul . Regarde les options -print0 de find
et -0 de xargs.
D'accord, je regarderai.
> Cette commande ne fait-elle que les rechercher et les afficher ?
« print »
Ok.
> À la lumière de quels critères peut-on savoir que la présence de
> liens orphelins placés ici où là est normale ?
Si tu ne sais pas, n'y touche pas.
Entendu. Je commencerai par produire une liste à partir de la ligne de
commande perl, et la posterai sur le forum de la distribution pour voir
quelles informations complémentaires je peux recueillir.
Que faudrait-il de plus dans cette commande pour envoyer la sortie dans
un fichier texte ? Dans bash je connais «
/chemin/vers/repertoire/un_fichier.txt », et dans perl, qu'est-ce qui
On 23 Aug 2009 14:07:52 GMT Nicolas George <nicolas$ wrote:
Le caractère n (retour à la ligne) peut apparaître dans un nom de fichier, pas le caractère nul . Regarde les options -print0 de find et -0 de xargs.
D'accord, je regarderai.
> Cette commande ne fait-elle que les rechercher et les afficher ?
« print »
Ok.
> À la lumière de quels critères peut-on savoir que la présence de > liens orphelins placés ici où là est normale ?
Si tu ne sais pas, n'y touche pas.
Entendu. Je commencerai par produire une liste à partir de la ligne de commande perl, et la posterai sur le forum de la distribution pour voir quelles informations complémentaires je peux recueillir.
Que faudrait-il de plus dans cette commande pour envoyer la sortie dans un fichier texte ? Dans bash je connais «
/chemin/vers/repertoire/un_fichier.txt », et dans perl, qu'est-ce qui
serait équivalent ?
Merci. :-)
Damien Wyart
* Mélodie in fr.comp.os.linux.configuration:
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 et enfin, les supprimer ? (Je suis à l'aise avec la console, sans toutefois savoir écrire des scripts shell)
Sur certaines distributions, on a la paquet symlinks, qui peut être utile pour ce genre de tâche :
Package: symlinks Priority: optional Section: utils Installed-Size: 72 Maintainer: Sven Joachim Architecture: i386 Version: 1.2-5 Depends: libc6 (>= 2.2) Filename: pool/main/s/symlinks/symlinks_1.2-5_i386.deb Size: 9604 MD5sum: deb95ae62c00eb6404b10fe6bbb6c7a0 SHA1: 8fc0c65bd06ab68f08617aca465b7263703625d8 SHA256: 56ae913d9c94cda4a53737bae5c4916cfadd8c17eab143eaebbcb5a9808b9f2e Description: scan/change symbolic links Symlinks scans directories for symbolic links and lists them on stdout. Each link is prefixed with a classification of relative, absolute, dangling, messy, lengthy or other_fs. . Symlinks can also convert absolute links (within the same filesystem) to relative links and can delete messy and dangling links.
-- DW
* Mélodie <melodie@nospam.eu> in fr.comp.os.linux.configuration:
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 et enfin, les supprimer ? (Je suis
à l'aise avec la console, sans toutefois savoir écrire des scripts
shell)
Sur certaines distributions, on a la paquet symlinks, qui peut être
utile pour ce genre de tâche :
Package: symlinks
Priority: optional
Section: utils
Installed-Size: 72
Maintainer: Sven Joachim <svenjoac@gmx.de>
Architecture: i386
Version: 1.2-5
Depends: libc6 (>= 2.2)
Filename: pool/main/s/symlinks/symlinks_1.2-5_i386.deb
Size: 9604
MD5sum: deb95ae62c00eb6404b10fe6bbb6c7a0
SHA1: 8fc0c65bd06ab68f08617aca465b7263703625d8
SHA256: 56ae913d9c94cda4a53737bae5c4916cfadd8c17eab143eaebbcb5a9808b9f2e
Description: scan/change symbolic links
Symlinks scans directories for symbolic links and lists
them on stdout. Each link is prefixed with a classification
of relative, absolute, dangling, messy, lengthy or other_fs.
.
Symlinks can also convert absolute links (within the same filesystem)
to relative links and can delete messy and dangling links.
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 et enfin, les supprimer ? (Je suis à l'aise avec la console, sans toutefois savoir écrire des scripts shell)
Sur certaines distributions, on a la paquet symlinks, qui peut être utile pour ce genre de tâche :
Package: symlinks Priority: optional Section: utils Installed-Size: 72 Maintainer: Sven Joachim Architecture: i386 Version: 1.2-5 Depends: libc6 (>= 2.2) Filename: pool/main/s/symlinks/symlinks_1.2-5_i386.deb Size: 9604 MD5sum: deb95ae62c00eb6404b10fe6bbb6c7a0 SHA1: 8fc0c65bd06ab68f08617aca465b7263703625d8 SHA256: 56ae913d9c94cda4a53737bae5c4916cfadd8c17eab143eaebbcb5a9808b9f2e Description: scan/change symbolic links Symlinks scans directories for symbolic links and lists them on stdout. Each link is prefixed with a classification of relative, absolute, dangling, messy, lengthy or other_fs. . Symlinks can also convert absolute links (within the same filesystem) to relative links and can delete messy and dangling links.
-- DW
Mélodie
On Mon, 24 Aug 2009 16:05:31 +0200 Damien Wyart wrote:
Sur certaines distributions, on a la paquet symlinks, qui peut être utile pour ce genre de tâche :
