POSIX tem a dizer sobre datas em uma listagem ls -l ong:
The <date and time> field shall contain the appropriate date and timestamp of when the file was last modified. In the POSIX locale, the field shall be the equivalent of the output of the following date command:
date "+%b %e %H:%M"
...if the file has been modified in the last six months, or:
date "+%b %e %Y"
Levando isso em consideração, e garantindo que, se houver novas linhas em um nome de arquivo, elas sejam apropriadamente distribuídas com a opção ls -q também POSIX especificada, é relativamente fácil preparar um regex para um resultado ls sem find de todos:
d=$(date "+%b %e") y=$(date --date=yesterday "+%b %e")
echo "$d" "$y"
###OUTPUT###
Jul 5 Jul 4
grep para isso e você retornará apenas as linhas que contêm as strings representando as datas de hoje ou de ontem. O comando a seguir adiciona isso um pouco:
ls -alRcq | sed "1H;/^-/!{/./d;N;h};/$d\|$y/!d;x;/\n/p;g"
ls opções consistem em:
-
-a retorna todos os arquivos em um diretório - incluindo aqueles que começam com .dot
-
% lista longa de
-l
-
-R lista recursivamente todos os diretórios filhos
-
-c exibe o tempo de modificação em vez do tempo de acesso
-
-q retorna o shell glob ? em vez de caracteres não imprimíveis ou \t ab em um nome de arquivo
Esses resultados são passados sobre o arquivo |pipe para sed , que corresponde apenas a:
- A linha em branco que precede um nome de caminho e a seguinte linha
- Linhas iniciadas com
- (em outras palavras, não d para o diretório) que também contêm date .
- Ele não imprime as linhas do nome do caminho, a menos que o diretório que ele nomeie contenha arquivos filtrados.
A saída é assim:
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
Sim, funciona mesmo com LS_COLORS - o que provavelmente é uma prioridade baixa para o seu cron , mas, ei, suas opções estão abertas.
Em qualquer caso, isso oferece algumas vantagens significativas sobre algumas outras soluções possíveis.
-
Em primeiro lugar, find + ls envolve várias invocações - isso envolve apenas um único processo ls , e é por isso que é possível classificar tudo de maneira confiável - o que acontece por padrão - e então sort também é feito auxiliar.
-
Qualquer solução envolvendo find e sort e ls está praticamente fazendo todo o trabalho duas vezes. ls e find resolverão todos os nomes de caminho e stat a cada arquivo. ls e sort classificarão todos os resultados. Provavelmente, é melhor usar apenas o único ls .
-
Então, é claro que há as partes date e sed dessa resposta. O que é importante notar é que você faz a parte difícil e obtém o regex primeiro - e apenas uma vez - e depois você apenas remove uma única lista de resultados em vez de dizer, obter resultados, obter resultados, classificar resultados e classificar resultados. p>
-
Isso não afeta nomes de arquivos que contêm novas linhas, como outras soluções provavelmente farão. Esta solução tem suas próprias ressalvas - o que eu explico a seguir -, mas elas são minuciosas e fáceis de lidar. Na minha opinião, esta é a solução mais robusta aqui.
Existem dois casos em que o comando acima pode causar problemas. O primeiro envolve o ? globs nos nomes dos arquivos - enquanto que como ele já é uma solução mais robusta do que qualquer outra oferecida aqui, e a probabilidade de você encontrar um ? é pequena o suficiente por conta própria, existe uma possibilidade de que resolver esses globs poderia corresponder a mais de um nome de arquivo. Consulte este para obter mais informações sobre este assunto.
A outra possibilidade envolve um falso positivo - por exemplo, se você tiver um nome de arquivo correspondente à string date para a qual estamos pesquisando com grep , mas que não foi realmente modificado em nenhum desses dias. Eu não estou contando com isso sendo um problema, mas, se for, pergunte sobre isso e eu provavelmente posso ajudá-lo a tornar o regex mais específico, a fim de lidar com isso.