POSIX має сказати про дати в ls
-l
списку онг:
<date and time>
Поле має містити відповідну дату і тимчасову мітку , коли в останній раз був змінений файл. У локалі POSIX поле повинно бути еквівалентом виводу наступної команди date:
date "+%b %e %H:%M"
... якщо файл було змінено за останні шість місяців, або:
date "+%b %e %Y"
Беручи це до уваги і гарантуючи, що якщо в імені файлу є якісь нові рядки, вони належним чином поширюються за допомогою вказаної також POSIX ls -q
опції, підготувати регекс для ls
результату порівняно просто find
:
d=$(date "+%b %e") y=$(date --date=yesterday "+%b %e")
echo "$d" "$y"
###OUTPUT###
Jul 5 Jul 4
grep
для цього і ви повернете лише рядки, що містять рядки, що представляють або сьогоднішні, або вчорашні дати. Наступна команда додає до цього трохи:
ls -alRcq | sed "1H;/^-/!{/./d;N;h};/$d\|$y/!d;x;/\n/p;g"
ls
варіанти складаються з:
-a
повернути всі файли в каталозі - включаючи ті, що починаються з a .dot
-l
довгий перелік
-R
рекурсивно перераховувати всі довідники
-c
відображення часу модифікації, а не часу доступу
-q
поверніть глобул оболонки, ?
а не символи , що не друкуються або \t
ab, у назві файлу
Ці результати передаються через |pipe
файл, sed
якому відповідають лише:
- Порожній рядок, що передує імені шляху, і наступний рядок
- Рядки, що починаються з
-
(іншими словами - не d
для каталогу), які також містять ваш date
.
- Він не друкує рядки імен шляхів, окрім випадків, коли каталог, який вони називають, фактично містить файли, за якими ви фільтрували.
Вихід виглядає приблизно так:
ls -alRcq --color=always |
sed "1H;/^-/!{/./d;N;h};/$d\|$y/!d;x;/\n/p;g"
###OUTPUT###
.:
-rw------- 1 mikeserv mikeserv 2086 Jul 4 10:52 .bash_history
-rw------- 1 mikeserv mikeserv 2657 Jul 4 15:20 .lesshst
-rw-r--r-- 1 mikeserv mikeserv 681 Jul 5 05:18 .zdirs
-rw------- 1 mikeserv mikeserv 750583 Jul 5 08:28 .zsh_history
-rw-r--r-- 1 mikeserv mikeserv 166 Jul 4 23:02 Terminology.log
-rw-r--r-- 1 mikeserv mikeserv 433568 Jul 4 13:34 shot-2014-06-22_17-10-16.jpg
-rw-r--r-- 1 mikeserv mikeserv 445192 Jul 4 13:34 shot-2014-06-22_17-11-06.jpg
./.cache/efreet:
-rw------- 1 mikeserv mikeserv 37325 Jul 4 22:51 desktop_localhost_C.eet
-rw------- 1 mikeserv mikeserv 37325 Jul 4 23:30 desktop_localhost_en_US.eet
-rw------- 1 mikeserv mikeserv 24090 Jul 4 22:51 desktop_util_localhost_C.eet
-rw------- 1 mikeserv mikeserv 24090 Jul 4 23:30 desktop_util_localhost_en_US.eet
-rw------- 1 mikeserv mikeserv 16037 Jul 4 23:30 icon_themes_localhost.eet
-rw------- 1 mikeserv mikeserv 3117 Jul 4 23:30 icons___efreet_fallback_localhost.eet
-rw------- 1 mikeserv mikeserv 768039 Jul 4 23:30 icons_gnome_localhost.eet
-rw------- 1 mikeserv mikeserv 18589 Jul 4 23:30 icons_hicolor_localhost.eet
./.config:
-rw-r--r-- 1 mikeserv mikeserv 30 Jul 4 19:10 pavucontrol.ini
./.config/chrome:
-rw-r--r-- 1 mikeserv mikeserv 94332179 Jul 4 13:36 conf.tar.lz4.bak
Так, це навіть працює з цим, LS_COLORS
що, мабуть, є низьким пріоритетом для вашого cron
курсу, але, можливо , ваші варіанти відкриті.
У будь-якому випадку це дає значні переваги перед деякими іншими можливими рішеннями.
В першу чергу find
+ ls
включає кілька викликів - це включає лише один ls
процес, і саме тому він може надійно сортувати все - що робиться за замовчуванням - і так sort
само робиться допоміжним.
Будь-яке рішення , що містить find
і sort
і ls
в значній мірі робить все роботи в два рази. ls
і find
вони вирішать кожне ім'я шляху та stat
кожен файл. ls
і sort
обидва будуть сортувати всі результати. Напевно, найкраще замість цього просто використати сингл ls
.
Тоді, звичайно, є date
і sed
частина цієї відповіді. Що важливо зауважити, це те, що ви виконуєте важку частину і отримуєте регекс спочатку - і лише один раз -, а потім лише обрізаєте єдиний список результатів, а не скажете, отримуєте результати, отримуєте результати, сортуєте результати та сортуєте результати.
Це не розбивається на назви файлів, що містять нові рядки, як, ймовірно, будуть інші рішення. У цього рішення є свої застереження - які я поясню далі - але вони є незначними та легко обробляються. На мою думку, це найбільш міцне рішення тут.
Є два випадки, коли вищевказана команда може викликати у вас проблеми. Перший стосується ?
глобусів у назви файлів - хоча це вже більш надійне рішення, ніж будь-яке інше, що пропонується тут, і ймовірність того, що ви зіткнетеся з ані ?
зовсім невеликою, існує ймовірність, що вирішити ці кулі може відповідати більше ніж одне ім’я файлу. Будь ласка, дивіться це для отримання додаткової інформації з цього приводу.
Інша можливість передбачає помилковий позитив - наприклад, якщо у вас є ім'я файлу, що фактично відповідає date
рядку, за яким ми шукаємо, grep
але фактично не було змінено жодного з цих днів. Я не розраховую на те, що це проблема, але, якщо вона є, запитайте про це, і я, мабуть, можу допомогти вам зробити регулярний вираз більш детальним, щоб вирішити це.
ls -ls **/*(.)