Найти последний файл по дате изменения

Если я захочу найти последний файл (mtime) в (большом) каталоге, содержащем подкаталоги, как бы я это сделал?

Множество найденных сообщений предлагают некоторые вариант ls -lt | head (забавно, многие предлагают ls -ltr | tail, который такой же, но менее эффективный), что хорошо, если у вас нет подкаталогов (у меня есть).

Опять же, вы могли бы

find . -type f -exec ls -lt \{\} \+ | head

, что определенно сделает трюк для столько файлов, сколько может быть указано одной командой, то есть, если у вас есть большой каталог , [ 113] будет выдавать отдельные команды; поэтому каждая группа будет отсортирована по ls внутри себя, но не по общему набору; Таким образом, головка подхватит последнюю запись первой партии.

Есть ответы?

38
задан 17 January 2014 в 06:10

6 ответов

Вам не нужно возвращаться к внешним командам (как ls), потому что find может сделать все, что вам нужно, с помощью действия -printf:

find /path -printf '%T+ %p\n' | sort -r | head
0
ответ дан 17 January 2014 в 06:10

У меня была похожая проблема сегодня, но я атаковал ее без find. Мне нужно было что-то короткое, чтобы я мог запустить ssh, чтобы вернуть последний отредактированный файл в моем домашнем каталоге. Это примерно то, что я придумал:

ls -tp | grep -v /$ | head -1

Опция -p для ls добавляет косую черту в каталоги, grep -v удаляет строки, заканчивающиеся косой чертой (иначе все каталоги) и head -1 ограничивает вывод одним файлом.

Это гораздо менее многословно, чем использование find, если все, что вы хотите вернуть - это имя файла.

0
ответ дан 17 January 2014 в 06:10

Это в моей системе быстрее, чем printf, хотя я не понимаю, почему

find /path -type f -exec stat -c "%y %n" {} + | sort -r | head
0
ответ дан 17 January 2014 в 06:10

Использовать perl в conjonctin с find :

 find my_directory -type f -printf '%T@\t%p\n' | perl -ane '@m=@F if ($F[0]>$m[0]); END{print $m[1];}'

Вы получаете название файла с самой большой эпохой == последний измененный файл.

2
ответ дан 17 January 2014 в 06:10

Это не так модно, но этого также можно достичь с помощью Midnight Commander : поиск *, группировка результатов, сортировка по времени изменения в обратном порядке.

Очевидно, это немного медленнее, чем find - мой домашний каталог, содержащий 922000 файлов, был отсортирован по mc почти за 14 минут, в то время как find потратил меньше 5 - но есть некоторые преимущества:

  • Вероятно, я бы потратил больше, чем разница в 9 минут, придумывая правильный вызов find:)

  • меньше шансов на ошибку (забыл указать -r для сортировки и т. д. - начните заново)

  • можно воспроизвести набор результатов, изменив порядок сортировки и т. д. - без повторного запроса файлов.

  • можно выполнять файловые операции только над некоторыми файлами из результирующего набора, то есть сортировать по размеру, удалять несколько больших файлов, которые не нужны

0
ответ дан 17 January 2014 в 06:10

Править: Я предполагаю, что это сообщение не 'не особенно полезно', поскольку я думал, что это было. Это - действительно быстрое решение, которое просто отслеживает последний раз измененный файл (вместо того, чтобы сортировать весь список файлов):

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 ' '

Распространение по нескольким строкам для ясности это смотрит следующим образом:

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 ' '

Конец РЕДАКТИРОВАНИЯ


Не особенно полезное сообщение, но начиная с 'расположения' обсуждало скорость, я думал, что совместно использую это.

решения расположения и enzotib включают список всех файлов в каталоге с их mtimes и затем сортировкой. Поскольку Вы знаете, что сортировка не необходима для нахождения максимума. Нахождение максимума может быть сделано в линейное время, но сортировка берет журнал n (n) время [я знаю, что различие не очень, но тем не менее ;)]. Я не могу думать об аккуратном способе реализовать это. [РЕДАКТИРОВАНИЕ: аккуратное (хотя грязный взгляд) и внедрение FAST, обеспеченное выше.]

Затем лучшая вещь - Для нахождения последний раз отредактированного файла в каталоге рекурсивно найдите последний раз отредактированный файл в каждом подкаталоге уровня 1. Позвольте этому файлу представить подкаталог. Теперь отсортируйте файлы уровня 1 вместе с представителями подкаталогов уровня 1. Если количество количества файлов уровня 1 и поддиректоров каждого каталога является почти константой, то этот процесс должен масштабироваться линейно с общим количеством файлов.

Это - то, что я придумал для реализации этого:

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 .

Я выполнил это и получил набор find: findrecent: No such file or directory ошибки. Причина: - должностное лицо находки работает в другой оболочке. Я пытался определить findrecent в .bashrc, .xsessionrc, но они не помогли [я буду ценить справку здесь]. В конце я обратился к помещению

#!/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;

в названном сценарии findrecent в моем ПУТИ и затем выполнении его.

Я выполнил это, заставленное ждать и ожидающий без вывода. Только, чтобы быть уверенным я не имел дело ни с какими бесконечными циклами, к которым я изменил файл

#!/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;

и попробованный еще раз. Это действительно работало - но заняло 1 минуту 35 секунд на моем homefolder - решения расположения и enzotib взяли 1.69, 1,95 секунды соответственно!

Так для O (n) превосходство над O (n журнал (n))! Прокляните Вас вызов функции наверху! [Или скорее сценарий звонит наверху]

Но этот сценарий действительно масштабируется лучше, чем более ранние решения, и я держал пари, что он будет работать быстрее, чем они на сегменте памяти Google; D

2
ответ дан 17 January 2014 в 06:10

Другие вопросы по тегам:

Похожие вопросы: