10/01/27 15:11:54
find ->(パイプ)-> md5
の場合、ファイル1個あたりにかかる時間はmd5の方がはるかに大きく、
find自体の動作はmd5の実行の裏プロセス(別CPU)で行なうから、
findの実行時間はすべてmd5の実行時間内に吸収されてしまって、
結局findの時間は無関係になる。
例: sleep 1 | sleep 10 ってやると、10秒で終了する。
左側のsleep 1は無関係になる。
もう1本のfindの、
find ->(パイプ)-> statコマンド
の方は、find->md5の方よりはるかに速いから、
2つのfindを名前付きパイプでpasteに接続する場合、
実行速度は遅い方の上流パイプであるmd5だけによって決まる。
よって、stat云々は一切関係なくなり、
名前付きパイプ+pasteが高速で動作する。
882:名無しさん＠お腹いっぱい。
10/01/27 15:18:31
LLが遅いと因縁つけてる奴は実測して証拠出せよ。ｗ
883:名無しさん＠お腹いっぱい。
10/01/27 15:34:47
>>860が言うようにtimeで計測すれば済む話なのになぜ誰もやらないのか
あ、俺はrubyとか知らないからパスね＾＾
誰かfindとperl/python/rubyでベンチ取ってよ
884:名無しさん＠お腹いっぱい。
10/01/27 16:40:18
適当に試してみたよ URLﾘﾝｸ(pastebin.com)
$ time test.bash >/dev/null
real 1m50.762s
user 0m17.992s
sys 0m4.473s
$ time test.py >/dev/null
real 1m49.994s
user 0m19.045s
sys 0m5.523s
885:名無しさん＠お腹いっぱい。
10/01/28 01:38:29
>>884
そのPythonのソースだと、各ファイルに対してstat()が最大3回呼ばれるのかな
886:名無しさん＠お腹いっぱい。
10/01/28 01:58:11
ま、どう考えてもMD5sum取る部分のI/O律速になるので
stat()の回数減らしたところで誤差程度だろうけど
887:名無しさん＠お腹いっぱい。
10/01/28 03:34:55
1000倍以上違うだろうね
888:名無しさん＠お腹いっぱい。
10/01/28 11:54:30
>>839
> find . -type f | xargs stat -f '%N,%z' > outputfile.txt
> find . -type f | xargs md5 $1 | sed -E 's/^MD5 \((.*)\) = (.*)/\1,\2/' > outputfile.txt
findは -print0でxrgsに渡し、xargsは -0で受け取るようにしましょう。
> find . -type f -print0 | xargs -0 stat -f '%N,%z' > outputfile.txt
> find . -type f | xargs -0 md5 | sed -E 's/^MD5 \((.*)\) = (.*)/\1,\2/' > outputfile.txt
URLﾘﾝｸ(www.otsune.com)
889:名無しさん＠お腹いっぱい。
10/01/28 17:51:27
こんなのfind + perl のワンライナーでいいじゃん
> find . -type f -print | perl -l0ne 'use Digest::MD5 qw(md5_hex);$s=-s $_;print $_ ." $s " . md5_hex($_) ."\n"'
890:名無しさん＠お腹いっぱい。
10/01/28 18:10:27
>>889
アフォか、ファイル名の md5 計算してどうする www
891:名無しさん＠お腹いっぱい。
10/01/28 18:13:23
>>888
日記だからある意味しょうがないのだが。そういう古臭いページなんとかならないもんかね。
892:名無しさん＠お腹いっぱい。
10/01/28 18:22:57
>>890
おー、いまperldocしたら
calculate the MD5 digest of this "message"
ってかいてあったｗｗはずかしいｗｗｗしぬかも
893:名無しさん＠お腹いっぱい。
10/01/28 19:05:07
>>891
どこがどう古臭いんだ？
894:名無しさん＠お腹いっぱい。
10/01/28 19:22:17
今書くなら「xargs捨てろ。 -exec {} +使え」
895:名無しさん＠お腹いっぱい。
10/01/28 19:22:36
>>894
一緒じゃないの？
896:名無しさん＠お腹いっぱい。
10/01/28 20:27:35
-exec だと正しく受け取れないファイルがある。
-print0 |xargs -0のほうが安全
897:名無しさん＠お腹いっぱい。
10/01/28 21:09:21
へー知らんかった
898:名無しさん＠お腹いっぱい。
10/01/28 21:11:42
>>896
原理的に有り得ないんだけど。
899:名無しさん＠お腹いっぱい。
10/01/28 21:13:42
どっちだよ気になるだろ
900:名無しさん＠お腹いっぱい。
10/01/28 21:37:46
-exec の + ターミネータ(;でなく)を知らないで答えていたりしてな。
901:名無しさん＠お腹いっぱい。
10/01/28 21:52:49
それにしても「正しく受け取れない」は原理的にない。
902:名無しさん＠お腹いっぱい。
10/01/28 22:08:06
いや、あるから -0 オプションが後から追加されたんですが。
903:名無しさん＠お腹いっぱい。
10/01/28 22:08:48
って、xargs じゃなくて find の方か。ならないや。ごめん。
904:名無しさん＠お腹いっぱい。
10/01/28 22:17:25
結局>>896は本当なのかどうなのか答えてくれ
つまり実際に-exec +だと受けとれないファイルがあるのか
それとも単に-exec ;と-exec +を混同してただけなのか
それと>>894の-exec +のほうが良いという根拠は何だ？
-print0 | xargs -0じゃいかんのか？
このままじゃ気になって寝れやしない
905:名無しさん＠お腹いっぱい。
10/01/28 22:42:34
>>904
> それと>>894の-exec +のほうが良いという根拠は何だ？
exec +がある環境ならxargsはレガシーコマンド。webで解説する必要は無い。
そもそも、exec +が無い環境がレガシー。 xargsはジジイの胸の奥にしまっておいてくれ。
906:名無しさん＠お腹いっぱい。
10/01/28 22:49:15
GNU findutilsにxargs付いてくるじゃない
907:名無しさん＠お腹いっぱい。
10/01/28 22:51:58
ジジイの懐古趣味
908:名無しさん＠お腹いっぱい。
10/01/29 01:55:18
xargs がいつobsolete になったの？
なんか文書ある？
909:名無しさん＠お腹いっぱい。
10/01/29 12:12:24
-exec + のデメリット
コマンドに渡すファイルの数を制御できない(xargs -n)
並列実行できない(xargs -P)
-exec + のメリット
find でひっかかったファイルが存在しなければコマンドが実行されない
（GNU xargs は入力がゼロでもなぜか1回は実行する; xargs -r で抑制可）
つーか、
ps ax | awk '/なんか条件/{print $1}' | xargs -r kill
みたいに find とは無関係に使う場合も多いから、obsolete のはずがない。
910:名無しさん＠お腹いっぱい。
10/01/29 16:58:01
findの-execはひとつひとつ実行するから遅いだろ。
grep /dev/null というバッドノウハウもアレだけど。（-h使えって？）
911:名無しさん＠お腹いっぱい。
10/01/29 17:01:35
>>910
find -exec + の 「+」の意味を理解していない方は発言を御遠慮ください
912:名無しさん＠お腹いっぱい。
10/01/30 09:34:03
>>910
レガシーちゃんｷﾀｰ
913:名無しさん＠お腹いっぱい。
10/01/30 09:38:13
MacのTimeMachineのようなことをするスクリプトを教えて
914:名無しさん＠お腹いっぱい。
10/01/30 10:01:33
pdumpfs
Rubyスクリプトだけどな。
915:名無しさん＠お腹いっぱい。
10/01/30 20:34:25
> -exec utility [argument ...] {} +
> Same as -exec, except that ``{}'' is replaced with as many path-
> names as possible for each invocation of utility. This behaviour
> is similar to that of xargs(1).
うおっ。-execに+なんて何時からあったんだ。
916:名無しさん＠お腹いっぱい。
10/01/30 20:41:41
URLﾘﾝｸ(www.gnu.org)
GNU findutils 4.2ぐらいからか
917:名無しさん＠お腹いっぱい。
10/01/30 21:09:21
-exec {} + テンプレに入ってるじゃねえかｗｗ
918:名無しさん＠お腹いっぱい。
10/01/30 22:00:29
ほんとだ。テンプレにあるな。
>findは -exec command {} + を推奨。
>他に -print0、xargsは -0オプションという方法もあるがSolaris非対応)
まるで -exec + ならば solaris でも使えるように書いてあるが、
実際は使えなかったような記憶が…
919:名無しさん＠お腹いっぱい。
10/01/31 02:34:28
>>913
つ URLﾘﾝｸ(wikis.sun.com)
920:名無しさん＠お腹いっぱい。
10/01/31 20:50:42
>>918
URLﾘﾝｸ(docs.sun.com)
921:名無しさん＠お腹いっぱい。
10/01/31 21:09:07
>>920
そのマニュアル、肝心なところを誤訳してるね。
日本語訳マニュアルは信用してはいけない。
922:名無しさん＠お腹いっぱい。
10/01/31 21:19:36
sunでもあるんだな。日本誤訳マニュアル
923:名無しさん＠お腹いっぱい。
10/02/01 01:46:35
原語は技術者が書いてても
翻訳は非技術者に丸投げだからね
924:名無しさん＠お腹いっぱい。
10/02/02 23:57:42
このスレ参考にファイル数が膨大なディレクトリで
paste -d, <(find $i -type f -exec stat -f '%N,%z' {} +) \
<(find $i -type f -exec md5 {} + | sed -E 's/^MD5 \(.*\) = (.*)/\1/') \
> output.txt
やったら
find: fts_read cannot allocate memory
出ました。Mac OSX
なぜ？ find のバグ？
925:名無しさん＠お腹いっぱい。
10/02/03 00:03:47
libftsのバグじゃね?