また、EDocにちょっとパッチを当てようかと思ったら、問題の根が深くて行き詰まりましたよ。
Unix風のフィルシステム／パス名と、DOS/Windowsのそれは違うのだけど、'/'と'\'の違いは大した問題じゃありません。空白や日本語文字を含む名前は困りものだけど、がんばればなんとかなりそう。でも、Windowsのドライブレターの扱いはほんとに困りますねー。
次のような前提で書かれたコードは多いですよね。
- ファイルパス名にコロンは含まれない。コロンが含まれるなら、それはURIスキームの区切りである(http: とか ftp: とか）。
- 絶対パスは先頭がスラッシュではじまる。それ以外は相対パスとみなせる。
- カレントディレクトリのパスはgetcwd()で取れる。カレントディレクトリのパスに相対パスを連結すると絶対パスができる。
このような想定で書かれたプログラムをWindowsのファイルシステム／パス名に適合させるにはどうすべきでしょう。まずは、ドライブ名付きルートをどう表現（マップ）すべきか？考えてみます。いくつかの候補を挙げましょう。
- c:/
- /c:/
- /c/
- /c|/
c:/ の形だと、Windowsプログラムに渡してもあまり問題が起きません。が、相対パスに見えてしまうので、/c:/ という形式が考えられます（Windows形式に戻すと問題が起きるかも知れませんがね）。しかしこれでもコロンが邪魔になるので、/c/ にするって案が三番目。だーけど、/c/ をWindowsに戻すと C:\c\ に解釈されそうです。/c|/ は昔Netscapeが使っていて、今のFiriefoxでも使えます*1が、特殊文字「|」が危なそう。
なんか八方塞がりですけど、それでもドライブ名付きルートはまだマシとも言えます。D:foo.txt のような「ドライブ名付き相対パス」をどう扱うべきか。D:foo.txt を絶対パスに直すために、getcwd()して連結すると、c:/tmp/d:foo.txt みたいになっちゃう。現ドライブとは限らないDドライブのカレントディレクトリを取得しなきゃならんのですが、そんな関数、Win32 APIにしかないですよね。お手上げー*2。
今みてるEDocの場合は、たまたま（ほんとにたまたま）いいかげんなパッチで結果オーライのようですが、ちょっとしたはずみで破綻＜はたん＞しそう。かといって、整合的な解決策も見あたらないし、あー悩ましい。
[追記]そういや、むかーし、マウントに似たJOINていうMS-DOSコマンドがあったような気がするけど、どうなったんでしょうね。JOINの仲間(?)みたいなSUBSTとかAPPENDとかは今でも残っているようですが。[/追記]
