なかだです。

At Wed, 7 Jan 2004 15:42:10 +0900,
H.Yamamoto wrote:
> ># それはそれとして、find -depthみたいにglobの順序を選べるといい
> ># かも。
> 
> glob_helper を２つ作って、フラグによって切り替えれば可能だと思います。

全体を二つ作る必要はないんじゃないでしょうか。

> ただ元の順序だと、
> 
> ・速度を犠牲にして dir.c.1 のロジックを使う。
> ・recursiveのほうをd_linkに格納して後で処理する。
>   その代わり、シンボリックリンクのチェックがタイムリーでなくなる。
> 
> のいずれかで妥協する必要があります。

a/, a/a1/, a/a1/a11, b/, b/b1/, b/b1/b11, c とあったときに、
glob("**/*")はこうなります。

$ ruby18 -e 'puts Dir.glob("**/*").join(" ")'
a b c a/a1 a/a1/a11 b/b1 b/b1/b11
$ ruby19 -e 'puts Dir.glob("**/*").join(" ")'
a/a1/a11 a/a1 a b/b1/b11 b/b1 b c

$ find -mindepth 1 -printf "%P "
a a/a1 a/a1/a11 b b/b1 b/b1/b11 c
$ find -mindepth 1 -depth -printf "%P "
a/a1/a11 a/a1 a b/b1/b11 b/b1 b c

findと比べてみると、今の1.9はfind -depth相当ですが、1.8はちょっ
と独自の順序です。どちらかというと、1.8の順序に戻すよりもfindの
デフォルトができたほうがいいように思うんですが。

> 私の中では、ブロック動作は順番を気にしない場合に使い、上からマッチしたいときは
> 
> Dir.glob('hoge/**/*').sort.each do |path|
>   # ...
> end
> 
> を使えばいいやと納得しました。でも、ファイル数が多い場合には選べるように
> したほうがいいのかなあ・・・ううむ。

というか、それは意味が違うのでは。例えば

  hoge/foo.c
  hoge/foo_c
  hoge/foo/c

があったとき、'hoge/**/*c'の結果は1.8、1.9、sortですべて別です。
順序が問題になるときには別の手段を考えろというのは同意ですが。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦