Je cherche un truc pour dater mes dossiers.
Sauf qu'un dossier peut avoir une date plus vielle que les fichiers
qu'il contient.
Je me demande donc comment chercher dans un dossier donné quels sont les
fichiers les plus récents.
J'ai tenté un find -mtime, mais il faut alors chercher mtime -1, puis
mtime -2, ... sinon j'avais pensé un ls -lR, mais il faut après faire le
tri... Bref je suppose qu'il y a un truc :)
Merci d'avance
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Je me demande donc comment chercher dans un dossier donné quels sont les fichiers les plus récents.
S'il n'y a pas trop de fichiers :
find . -type f -print | xargs ls -t | head
Ah, bin selon ce que j'ai testé ça ne passe pas avec les nom comportants des espaces. ça ne serait pas plutôt ceci : find . -type f -print0 |xargs -0 ls -t | head
A propos du "trop grand nombre de fichiers", on peut dans ce cas faire :
find . -type f -fprintf /tmp/findtemp "%TY%Tm%Td %TT %pn" 2>/dev/null sort -o /tmp/sorttemp -r /temp/findtemp head /tmp/sorttemp rm /tmp/sorttemp /tmp/findtemp
non ? (à moins que la méthode de Pascal soit à l'abris de mes 800'000 fichiers, ce dont je doutes)
Il n'y a aucun problème à passer 800000 lignes via un pipe. ON N'EST PAS SUR MS-DOS!
Mais si tu as des espaces dans tes noms de fichiers, sache que nos méthodes ne fonctionneront pas s'ils ont aussi des new-line!
Je me demande donc comment chercher dans un dossier donné quels sont les
fichiers les plus récents.
S'il n'y a pas trop de fichiers :
find . -type f -print | xargs ls -t | head
Ah, bin selon ce que j'ai testé ça ne passe pas avec les nom comportants
des espaces.
ça ne serait pas plutôt ceci :
find . -type f -print0 |xargs -0 ls -t | head
A propos du "trop grand nombre de fichiers", on peut dans ce cas faire :
find . -type f -fprintf /tmp/findtemp "%TY%Tm%Td %TT %pn" 2>/dev/null
sort -o /tmp/sorttemp -r /temp/findtemp
head /tmp/sorttemp
rm /tmp/sorttemp /tmp/findtemp
non ?
(à moins que la méthode de Pascal soit à l'abris de mes 800'000
fichiers, ce dont je doutes)
Il n'y a aucun problème à passer 800000 lignes via un pipe.
ON N'EST PAS SUR MS-DOS!
Mais si tu as des espaces dans tes noms de fichiers, sache que nos
méthodes ne fonctionneront pas s'ils ont aussi des new-line!
Je me demande donc comment chercher dans un dossier donné quels sont les fichiers les plus récents.
S'il n'y a pas trop de fichiers :
find . -type f -print | xargs ls -t | head
Ah, bin selon ce que j'ai testé ça ne passe pas avec les nom comportants des espaces. ça ne serait pas plutôt ceci : find . -type f -print0 |xargs -0 ls -t | head
A propos du "trop grand nombre de fichiers", on peut dans ce cas faire :
find . -type f -fprintf /tmp/findtemp "%TY%Tm%Td %TT %pn" 2>/dev/null sort -o /tmp/sorttemp -r /temp/findtemp head /tmp/sorttemp rm /tmp/sorttemp /tmp/findtemp
non ? (à moins que la méthode de Pascal soit à l'abris de mes 800'000 fichiers, ce dont je doutes)
Il n'y a aucun problème à passer 800000 lignes via un pipe. ON N'EST PAS SUR MS-DOS!
Mais si tu as des espaces dans tes noms de fichiers, sache que nos méthodes ne fonctionneront pas s'ils ont aussi des new-line!
The world will now reboot. don't bother saving your artefacts.
Nicolas.MICHEL
Nicolas George <nicolas$ wrote:
C'est exactement la même méthode, sauf que la communication entre find et sort se fait avec un pipe
Oui, mais quelle est la limite de taille d'une pipe ?
J'ai ici un vieux bouquin qui dit, euh, je ne l'ai pas sous la main en fait. Mais j'ai déjà eu des "find ... |xargs" qui partaient aux fraises à cause d'un résultat trop long il me semble. Je ne sais par contre plus le contexte.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Nicolas George <nicolas$george@salle-s.org> wrote:
C'est exactement la même méthode, sauf que la communication entre find et
sort se fait avec un pipe
Oui, mais quelle est la limite de taille d'une pipe ?
J'ai ici un vieux bouquin qui dit, euh, je ne l'ai pas sous la main en
fait. Mais j'ai déjà eu des "find ... |xargs" qui partaient aux fraises
à cause d'un résultat trop long il me semble. Je ne sais par contre plus
le contexte.
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
C'est exactement la même méthode, sauf que la communication entre find et sort se fait avec un pipe
Oui, mais quelle est la limite de taille d'une pipe ?
J'ai ici un vieux bouquin qui dit, euh, je ne l'ai pas sous la main en fait. Mais j'ai déjà eu des "find ... |xargs" qui partaient aux fraises à cause d'un résultat trop long il me semble. Je ne sais par contre plus le contexte.
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
Nicolas George
Nicolas MICHEL wrote in message <1gx8d2d.kjkgpofkpi6lN%:
Oui, mais quelle est la limite de taille d'une pipe ?
Aucune. En revanche, pour les fichiers, la taille du filesystem est souvent limitée.
J'ai ici un vieux bouquin qui dit, euh, je ne l'ai pas sous la main en fait. Mais j'ai déjà eu des "find ... |xargs" qui partaient aux fraises à cause d'un résultat trop long il me semble.
Avec xargs ça ne devrait pas arriver, justement parce que xargs est prévu pour éviter ça. Ça peut arriver avec « frobnicate `find ...` » à cause de la limite sur les arguments d'une commande, mais xargs est précisément prévu pour découper les arguments en blocs assez petits.
Nicolas MICHEL wrote in message
<1gx8d2d.kjkgpofkpi6lN%Nicolas.MICHEL@BonBon.net>:
Oui, mais quelle est la limite de taille d'une pipe ?
Aucune. En revanche, pour les fichiers, la taille du filesystem est souvent
limitée.
J'ai ici un vieux bouquin qui dit, euh, je ne l'ai pas sous la main en
fait. Mais j'ai déjà eu des "find ... |xargs" qui partaient aux fraises
à cause d'un résultat trop long il me semble.
Avec xargs ça ne devrait pas arriver, justement parce que xargs est prévu
pour éviter ça. Ça peut arriver avec « frobnicate `find ...` » à cause de la
limite sur les arguments d'une commande, mais xargs est précisément prévu
pour découper les arguments en blocs assez petits.
Nicolas MICHEL wrote in message <1gx8d2d.kjkgpofkpi6lN%:
Oui, mais quelle est la limite de taille d'une pipe ?
Aucune. En revanche, pour les fichiers, la taille du filesystem est souvent limitée.
J'ai ici un vieux bouquin qui dit, euh, je ne l'ai pas sous la main en fait. Mais j'ai déjà eu des "find ... |xargs" qui partaient aux fraises à cause d'un résultat trop long il me semble.
Avec xargs ça ne devrait pas arriver, justement parce que xargs est prévu pour éviter ça. Ça peut arriver avec « frobnicate `find ...` » à cause de la limite sur les arguments d'une commande, mais xargs est précisément prévu pour découper les arguments en blocs assez petits.
TiChou
Dans le message <news:, *Pascal Bourguignon* tapota sur f.c.o.unix :
Laurent Wacrenier wrote:
S'il n'y a pas trop de fichiers :
find . -type f -print | xargs ls -t | head
writes:
A propos du "trop grand nombre de fichiers", on peut dans ce cas faire :
find . -type f -fprintf /tmp/findtemp "%TY%Tm%Td %TT %pn" 2>/dev/null sort -o /tmp/sorttemp -r /temp/findtemp head /tmp/sorttemp rm /tmp/sorttemp /tmp/findtemp
non ?
Oui, mais puisque vous utilisez le GNU find il y a alors plus simple :
find . -type f -printf "%T@ %pn" | sort | head
Sans les outils GNU, on peut aussi s'orienter vers un simple script perl et la fonction stat :
#!/usr/bin/perl
use strict;
my $dir = $ARGV[0];
opendir(DIR, $dir) or die "Can't open dir $dir: $!n"; print (sort { ((stat($b))[9] <=> (stat($a))[9]} readdir(DIR))[0] . "n"; closedir(DIR);
(à moins que la méthode de Pascal soit à l'abris de mes 800'000 fichiers, ce dont je doutes)
Il n'y a aucun problème à passer 800000 lignes via un pipe. ON N'EST PAS SUR MS-DOS!
Qui a parlé d'un problème à ce sujet ?
Le problème est, comme nous l'avons tous compris, qu'on est limité par le nombre d'arguments (largement inférieur à 800 000) qui peuvent être passés à une commande shell. Ici la solution de Laurent Wacrenier ne fera apparaître les fichiers les plus récents que seulement de la première série d'arguments envoyé par xargs à la commande 'ls', bref, peu de chance parmi les 800 000 fichiers d'avoir les plus récents dans la première série d'arguments. C'est bien pour cela que Laurent Wacrenier faisait remarquer que sa solution ne fonctionnera qu'avec un nombre réduit de fichiers.
-- TiChou
Dans le message <news:873bs8hi4n.fsf@thalassa.informatimago.com>,
*Pascal Bourguignon* tapota sur f.c.o.unix :
Laurent Wacrenier <lwa@teaser.fr> wrote:
S'il n'y a pas trop de fichiers :
find . -type f -print | xargs ls -t | head
Nicolas.MICHEL@BonBon.net writes:
A propos du "trop grand nombre de fichiers", on peut dans ce cas faire :
find . -type f -fprintf /tmp/findtemp "%TY%Tm%Td %TT %pn" 2>/dev/null
sort -o /tmp/sorttemp -r /temp/findtemp
head /tmp/sorttemp
rm /tmp/sorttemp /tmp/findtemp
non ?
Oui, mais puisque vous utilisez le GNU find il y a alors plus simple :
find . -type f -printf "%T@ %pn" | sort | head
Sans les outils GNU, on peut aussi s'orienter vers un simple script perl et
la fonction stat :
#!/usr/bin/perl
use strict;
my $dir = $ARGV[0];
opendir(DIR, $dir) or die "Can't open dir $dir: $!n";
print (sort { ((stat($b))[9] <=> (stat($a))[9]} readdir(DIR))[0] . "n";
closedir(DIR);
(à moins que la méthode de Pascal soit à l'abris de mes 800'000
fichiers, ce dont je doutes)
Il n'y a aucun problème à passer 800000 lignes via un pipe.
ON N'EST PAS SUR MS-DOS!
Qui a parlé d'un problème à ce sujet ?
Le problème est, comme nous l'avons tous compris, qu'on est limité par le
nombre d'arguments (largement inférieur à 800 000) qui peuvent être passés à
une commande shell.
Ici la solution de Laurent Wacrenier ne fera apparaître les fichiers les
plus récents que seulement de la première série d'arguments envoyé par xargs
à la commande 'ls', bref, peu de chance parmi les 800 000 fichiers d'avoir
les plus récents dans la première série d'arguments. C'est bien pour cela
que Laurent Wacrenier faisait remarquer que sa solution ne fonctionnera
qu'avec un nombre réduit de fichiers.
Dans le message <news:, *Pascal Bourguignon* tapota sur f.c.o.unix :
Laurent Wacrenier wrote:
S'il n'y a pas trop de fichiers :
find . -type f -print | xargs ls -t | head
writes:
A propos du "trop grand nombre de fichiers", on peut dans ce cas faire :
find . -type f -fprintf /tmp/findtemp "%TY%Tm%Td %TT %pn" 2>/dev/null sort -o /tmp/sorttemp -r /temp/findtemp head /tmp/sorttemp rm /tmp/sorttemp /tmp/findtemp
non ?
Oui, mais puisque vous utilisez le GNU find il y a alors plus simple :
find . -type f -printf "%T@ %pn" | sort | head
Sans les outils GNU, on peut aussi s'orienter vers un simple script perl et la fonction stat :
#!/usr/bin/perl
use strict;
my $dir = $ARGV[0];
opendir(DIR, $dir) or die "Can't open dir $dir: $!n"; print (sort { ((stat($b))[9] <=> (stat($a))[9]} readdir(DIR))[0] . "n"; closedir(DIR);
(à moins que la méthode de Pascal soit à l'abris de mes 800'000 fichiers, ce dont je doutes)
Il n'y a aucun problème à passer 800000 lignes via un pipe. ON N'EST PAS SUR MS-DOS!
Qui a parlé d'un problème à ce sujet ?
Le problème est, comme nous l'avons tous compris, qu'on est limité par le nombre d'arguments (largement inférieur à 800 000) qui peuvent être passés à une commande shell. Ici la solution de Laurent Wacrenier ne fera apparaître les fichiers les plus récents que seulement de la première série d'arguments envoyé par xargs à la commande 'ls', bref, peu de chance parmi les 800 000 fichiers d'avoir les plus récents dans la première série d'arguments. C'est bien pour cela que Laurent Wacrenier faisait remarquer que sa solution ne fonctionnera qu'avec un nombre réduit de fichiers.
-- TiChou
Nicolas.MICHEL
"TiChou" wrote:
Qui a parlé d'un problème à ce sujet ?
Moi, je pensais que les pipe avaient une limitations de taille, ce qui n'est donc pas le cas.
Le problème est, comme nous l'avons tous compris, qu'on est limité par le nombre d'arguments (largement inférieur à 800 000) qui peuvent être passés à une commande shell. Ici la solution de Laurent Wacrenier ne fera apparaître les fichiers les plus récents que seulement de la première série d'arguments envoyé par xargs à la commande 'ls', bref, peu de chance parmi les 800 000 fichiers d'avoir les plus récents dans la première série d'arguments. C'est bien pour cela que Laurent Wacrenier faisait remarquer que sa solution ne fonctionnera qu'avec un nombre réduit de fichiers.
Merci à toi et à Nicolas pour ces précisions :)
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
"TiChou" <gro.uohcit@uohcit> wrote:
Qui a parlé d'un problème à ce sujet ?
Moi, je pensais que les pipe avaient une limitations de taille, ce qui
n'est donc pas le cas.
Le problème est, comme nous l'avons tous compris, qu'on est limité par le
nombre d'arguments (largement inférieur à 800 000) qui peuvent être passés à
une commande shell.
Ici la solution de Laurent Wacrenier ne fera apparaître les fichiers les
plus récents que seulement de la première série d'arguments envoyé par xargs
à la commande 'ls', bref, peu de chance parmi les 800 000 fichiers d'avoir
les plus récents dans la première série d'arguments. C'est bien pour cela
que Laurent Wacrenier faisait remarquer que sa solution ne fonctionnera
qu'avec un nombre réduit de fichiers.
Merci à toi et à Nicolas pour ces précisions :)
--
S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes
iChat/AIM : michelnicolas
Moi, je pensais que les pipe avaient une limitations de taille, ce qui n'est donc pas le cas.
Le problème est, comme nous l'avons tous compris, qu'on est limité par le nombre d'arguments (largement inférieur à 800 000) qui peuvent être passés à une commande shell. Ici la solution de Laurent Wacrenier ne fera apparaître les fichiers les plus récents que seulement de la première série d'arguments envoyé par xargs à la commande 'ls', bref, peu de chance parmi les 800 000 fichiers d'avoir les plus récents dans la première série d'arguments. C'est bien pour cela que Laurent Wacrenier faisait remarquer que sa solution ne fonctionnera qu'avec un nombre réduit de fichiers.
Merci à toi et à Nicolas pour ces précisions :)
-- S'il n'y a pas de solutions, c'est qu'il n'y a pas de problèmes iChat/AIM : michelnicolas
