編集:この投稿は、私が思ったほど「特に有用ではない」とは思いません。これは、ファイルのリスト全体をソートするのではなく、最後に変更されたファイルを追跡するだけの非常に高速なソリューションです。
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
エラー。理由:findの-execが別のシェルで実行されます。.bashrc、.xsessionrcでfindrecentを定義しようとしましたが、助けにはなりませんでした[ここで助けていただければ幸いです]。最後に私はパッティングに頼った
#!/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
PATHで呼び出されたスクリプトで実行します。
私はこれを実行し、何も出力せずに待ち続けました。ただ、無限ループを処理していないことを確認するために、ファイルを
#!/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秒かかりましたが、arrangeとenzotibのソリューションはそれぞれ1.69、1.95秒かかりました!
O(n)のO(n log(n))に対する優位性はこれだけです!くそー関数呼び出しのオーバーヘッド![むしろ、スクリプト呼び出しのオーバーヘッド]
しかし、このスクリプトは以前のソリューションよりも優れた拡張性を備えており、Googleのメモリバンクで実行するよりも速く実行されるに違いありません; D