EDIT : Je pense que ce post n'est pas "pas particulièrement utile" comme je le pensais. Il s'agit d'une solution très rapide qui se contente de garder la trace du fichier le plus récemment modifié (au lieu de trier toute la liste des fichiers) :
find . -type f -printf '%T@ %p\n' | awk 'BEGIN { mostrecenttime = 0; mostrecentline = "nothing"; } { if ($1 > mostrecenttime) { mostrecenttime = $1; mostrecentline = $0; } } END { print mostrecentline; }' | cut -f2- -d ' '
Réparti sur plusieurs lignes pour plus de clarté, il se présente comme suit :
find . -type f -printf '%T@ %p\n' | awk '
BEGIN { mostrecenttime = 0; mostrecentline = "nothing"; }
{
if ($1 > mostrecenttime)
{ mostrecenttime = $1; mostrecentline = $0; }
}
END { print mostrecentline; }' | cut -f2- -d ' '
Fin de l'EDIT
Il ne s'agit pas d'un article particulièrement utile, mais comme "arrange" parlait de vitesse, j'ai pensé le partager.
Les solutions d'arrange et d'enzotib consistent à lister tous les fichiers du répertoire avec leurs mtimes, puis à les trier. Comme vous le savez, le tri n'est pas nécessaire pour trouver le maximum. Trouver le maximum peut être fait en temps linéaire mais le tri prend n log(n) temps [je sais que la différence n'est pas énorme, mais quand même ;)]. Je n'arrive pas à trouver une façon élégante d'implémenter cela. [EDIT : Une implémentation rapide et soignée (bien qu'elle ait l'air sale) est fournie ci-dessus].
Prochaine meilleure solution - Pour trouver le fichier le plus récemment édité dans un répertoire, recherchez récursivement le fichier le plus récemment édité dans chaque sous-répertoire de niveau 1. Ce fichier représente le sous-répertoire. Triez ensuite les fichiers de niveau 1 avec les représentants des sous-répertoires de niveau 1. Si le nombre de fichiers de niveau 1 et de sous-répertoires de chaque répertoire est presque constant, ce processus devrait s'échelonner linéairement avec le nombre total de fichiers.
Voici ce que j'ai trouvé pour mettre cela en œuvre :
findrecent() { { find "$1" -maxdepth 1 -type f -exec stat -c "%y %n" {} + | sort -r | head -1 && find "$1" -mindepth 1 -maxdepth 1 -type d -exec findrecent {} \;; } | sort -r | head -1; }
findrecent .
Je l'ai lancé et j'ai obtenu un grand nombre de find: findrecent: No such file or directory erreurs. Raison : -exec de find s'exécute dans un Shell différent. J'ai essayé de définir findrecent dans .bashrc, .xsessionrc mais cela n'a pas aidé [j'apprécierais de l'aide ici]. En fin de compte, j'ai dû mettre
#!/bin/bash
{ find "$1" -maxdepth 1 -type f -exec stat -c "%y %n" {} + | sort -r | head -1 && find "$1" -mindepth 1 -maxdepth 1 -type d -exec findrecent {} \;; } | sort -r | head -1;
dans un script appelé findrecent dans mon PATH et de l'exécuter.
J'ai exécuté ce programme, qui n'a cessé d'attendre, sans résultat. Pour être sûr de ne pas avoir affaire à des boucles infinies, j'ai modifié le fichier en
#!/bin/bash
echo "$1" >&2
{ find "$1" -maxdepth 1 -type f -exec stat -c "%y %n" {} + | sort -r | head -1 && find "$1" -mindepth 1 -maxdepth 1 -type d -exec findrecent {} \;; } | sort -r | head -1;
et a réessayé. Cela a fonctionné - mais a pris 1 minute 35 secondes sur mon dossier personnel - les solutions d'arrange et d'enzotib ont pris respectivement 1,69 et 1,95 secondes !
Voilà pour la supériorité de O(n) sur O(n log (n)) ! Maudit soit le surcoût des appels de fonction ! [Ou plutôt script surcharge d'appels de fonctions].
Mais ce script s'adapte mieux que les solutions précédentes et je parie qu'il fonctionnera plus vite qu'elles sur la banque de mémoire de Google ;D
