--pgp-sign-Multipart_Fri_Sep_26_08:13:04_2008-1
Content-Type: text/plain; charset=ISO-2022-JP

At Fri, 26 Sep 2008 02:29:43 +0900,
Tanaka Akira wrote:
> In article <86ljxgd0jt.knu / iDaemons.org>,
>   "Akinori MUSHA" <knu / iDaemons.org> writes:
>
> >  しかし、 real という単語が入るのに実際に存在しないパスを返す
> > のは奇妙ではないでしょうか。あくまで realpath という既知の名前
> > からしか機能は想起されないと思います。real_path は気持ち悪いし、
> > *_realpath や realpath_* も適当なものが思いつきませんでした。
> > bsd_realpath, realpath_butlast, realpath_till_penult,
> > almost_realpath, not_quite_realpath, ...
>
> 奇妙になるかどうかは名前の作りかた次第と思います。たとえば
> realdir とすれば、real なのは dir と受け取れるでしょう。
> dir だけが real とも受け取れるのが問題なのですが。

 realdirpath とか?勝手な造語のようで気が引けますが…。

> >  同じ機能は既存の公開および内部メソッドを使っても簡単には実装
> > できなかったのでなんとか入れたいと思うのですが。
>
> えーと、
>
>   if path.exist?
>     path.realname
>   elsif path.dirname.directory?
>     path.dirname.realpath + path.basename
>   else
>     raise Errno::ENOTDIR
>   end
>
> くらいではうまくいきませんかね。

最初の elsif の前に

    elsif path.symlink?
      dir, base = path.readlink.split
      (path.dirname + dir).realpath + base

も必要です。これだとメソッドにしたくなります。

> >  ~ の展開と相対パスの展開を行うメソッドが expand_path なので、
> > symlink の解決と相対パスの展開を行うメソッドが resolve_path と
> > いうのは悪くないと思っています。realpath との関連はさほど大事
> > でしょうか。
>
> symlink の解決と相対パスの展開を行うというのはまさに
> realpath で、望まれている機能からは realpath に近いでしょう。

 *BSD ではそれが realpath ですしね。ただ、そのために混乱を引き
ずりそうなので新しい名前がいいかもしれないと思いました。

> あと、expand_path は ~ を扱うのがいやらしいと思っていて、で
> きれば無視したいところです。

 ~ の展開機能はどのように提供するのがいいんでしょう。手元では
Pathname.new(filespec).expand_path.realpath のような並びになる
ことが多いです。

--
Akinori MUSHA / http://akinori.org/

--pgp-sign-Multipart_Fri_Sep_26_08:13:04_2008-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEABECAAYFAkjcGwAACgkQkgvvx5/Z4e7wZACg0D1DxWfOzlwpceCC40fXPePy
0GcAoNl2hyhnGeNSp3AyucbGRc4ARraj
=2HL8
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Fri_Sep_26_08:13:04_2008-1--