[#47869] [Mac OS X] Dir.glob で取得したファイル名のバイト列が異なる — Watson <watson1978@...>
Ruby 2.0 =1B$B$^$G$O=1B(B OS X =1B$B$N%U%!%$%kL>$r=1B(B Dir.glob =
7 messages
2014/01/03
[#47875] Re: [Mac OS X] Dir.glob で取得したファイル名のバイト列が異なる
— "NARUSE, Yui" <naruse@...>
2014/01/09
端的には仕様変更です。
[#47876] Re: [Mac OS X] Dir.glob で取得したファイル名のバイト列が異なる
— Watson <watson1978@...>
2014/01/09
ご返答ありがとうございます。
[#47903] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations — Tanaka Akira <akr@...>
2014/1/19 <[email protected]>:
7 messages
2014/01/19
[#47904] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations
— Nobuyoshi Nakada <nobu@...>
2014/01/19
(2014/01/19 10:17), Tanaka Akira wrote:
[#47905] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations
— Tanaka Akira <akr@...>
2014/01/19
2014年1月19日 16:20 Nobuyoshi Nakada <[email protected]>:
[#47907] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations
— Nobuyoshi Nakada <nobu@...>
2014/01/19
(2014/01/19 16:48), Tanaka Akira wrote:
[#47908] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations
— Tanaka Akira <akr@...>
2014/01/19
2014年1月19日 18:12 Nobuyoshi Nakada <[email protected]>:
[#47917] Re: [ruby-changes:32633] nobu:r44712 (trunk): thread_pthread.c: get current main thread stack size — KOSAKI Motohiro <kosaki.motohiro@...>
Ruby-devに河岸をうつしました。
5 messages
2014/01/28
[#47918] Re: [ruby-changes:32633] nobu:r44712 (trunk): thread_pthread.c: get current main thread stack size
— Nobuyoshi Nakada <nobu@...>
2014/01/28
なかだです。
[#47919] Re: [ruby-changes:32633] nobu:r44712 (trunk): thread_pthread.c: get current main thread stack size
— "NARUSE, Yui" <naruse@...>
2014/01/28
スレッドのスタック情報の取得は前にまとめたことがありますが、
[ruby-dev:47879] Re: [Mac OS X] Dir.glob で取得したファイル名のバイト列が異なる
From:
"NARUSE, Yui" <naruse@...>
Date:
2014-01-09 06:02:43 UTC
List:
ruby-dev #47879
「ファイルが存在するか」のチェックでしたら、Dir.globで取得したものと比較ではなく、 File.exist?(ファイル名)の方がいいですよ。 2.1のString#encodeは一通り確認して実際のファイルシステムと同じように動くようにしたつもりですが、 将来のバージョンで挙動が変化する可能性はありますし、 HFS+は通常case insensitiveでマウントされますから、HFS+と同じcase insensitiveな比較も必要です。 で、もちろんcase sensitiveでマウントされることもありえます。 などを考慮すると、素直にファイルシステムに聞くのが一番です。 2014年1月9日 10:17 Watson <[email protected]>: > RubyMotion で iOS/OSX アプリをビルドする際に CRuby を使用しております。 > ビルドする途中で、ユーザが指定したアプリ名のファイルが存在しているか > チェックする処理があり、Dir.glob を用いてファイル名を取得しております。 > > 以前 String#encode で Normalization Form D から Normalization Form C へ > 変換できない問題があり報告しております。 > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/47680 > > そのため、ユーザがアプリをビルドする際に CRuby 1.8、1.9 や 2.0 を利用し > ていても > 動くようにファイル名を扱う箇所を Normalization Form D で統一していたため、 > 今回報告した内容について遭遇した次第です。 > > (2014/01/09 10:04), NARUSE, Yui wrote: >> OS XのHFS+上のファイル名をRubyでどう扱うべきかについては、 >> 今でも知見が十分に得られているとは言い難いので、 >> どのような問題に遭遇したのか共有していただけると助かります。 >> >> 2014年1月9日 10:02 Watson <[email protected]>: >>> ご返答ありがとうございます。 >>> >>> 仕様変更ということなので、今後再び振る舞いが変わることがなさそうなので、 >>> 現在、私が遭遇している問題についてはこちらで対処したいと思います。 >>> >>> >>> ありがとうございました。 >>> >>> (2014/01/09 9:53), NARUSE, Yui wrote: >>>> 端的には仕様変更です。 >>>> 長大な議論の果てに変更されたわけなのですが、詳細をすぐには思い出せないので、 >>>> さしあたっては http://bugs.ruby-lang.org/issues/7267 を御覧ください。 >>>> 解説が必要でしたら解説します。 >>>> >>>> 2014年1月3日 16:33 Watson <[email protected]>: >>>>> Ruby 2.0 までは OS X のファイル名を Dir.glob で取得したときには >>>>> OS X ファイルシステムが返す Normalization Form D バイト列が Dir.glob で >>>>> 取得されておりました。 >>>>> >>>>> Ruby 2.1 からは Normalization Form C に変換したバイト列が Dir.glob で >>>>> 取得されるようになっているようなのですが、仕様が変わったのでしょうか？ >>>>> >>>>> % cat test.rb >>>>> system "touch 'が'" >>>>> Dir.glob("*").each do |file| >>>>> next if file == $0 >>>>> puts "** #{file} **" >>>>> file.each_byte do |b| >>>>> p b >>>>> end >>>>> end >>>>> >>>>> % ruby -v test.rb >>>>> ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13] >>>>> ** が ** >>>>> 227 >>>>> 129 >>>>> 139 >>>>> 227 >>>>> 130 >>>>> 153 >>>>> >>>>> % ruby -v test.rb >>>>> ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin13.0] >>>>> ** が ** >>>>> 227 >>>>> 129 >>>>> 140 >>>> >> >> > -- NARUSE, Yui <[email protected]>