РЕДАКТИРОВАТЬ: Я предполагаю, что этот пост не является "не особенно полезным", как я думал. Это действительно быстрое решение, которое просто отслеживает самый последний измененный файл (вместо сортировки всего списка файлов).:
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 ' '
Конец РЕДАКТИРОВАНИЯ
Не особенно полезный пост, но поскольку в "аранжировке" обсуждалась скорость, я подумал, что поделюсь этим.
Решения arrange и enzotib включают в себя перечисление всех файлов внутри каталога с указанием их mtimes, а затем сортировку. Как вы знаете, сортировка не является необходимой для поиска максимума. Нахождение максимума может быть выполнено за линейное время, но сортировка занимает n log(n) времени [Я знаю, что разница невелика, но все же ;)]. Я не могу придумать аккуратного способа реализации этого. [ПРАВКА: аккуратная (хотя и грязная на вид) и быстрая реализация, представленная выше.]
Следующая лучшая вещь - чтобы найти последний отредактированный файл в каталоге, рекурсивно найдите последний отредактированный файл в каждом подкаталоге уровня 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 ошибки. Причина: -exec find выполняется в другой оболочке. Я попытался определить 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/bashecho "$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 секунд на моем домашнем заполнителе - решения arrange и enzotib заняли 1,69 и 1,95 секунды соответственно!
Вот вам и превосходство O(n) над O(n log (n))! Будь ты проклят, накладные расходы на вызов функций! [Или, скорее, накладные расходы на вызов скрипта]
Но этот скрипт масштабируется лучше, чем предыдущие решения, и я уверен, что он будет работать быстрее, чем они, в банке памяти Google ; D