On Wed, Feb 22, 2012 at 5:46 AM, Nicholas Clark <nick@ccl4.org> wrote: > On Wed, Feb 22, 2012 at 05:42:47AM +0100, Ricardo Signes wrote: > > > commit b581a1f73be55ae99bb4ce6f49883b0b717b5142 > > Author: Ricardo Signes <rjbs@cpan.org> > > Date: Tue Feb 21 22:19:56 2012 -0500 > > > > unixify the --outfile arg to pod2html > > > > I think we probably need a more systematic regimen of of unixify > > calls, but for now, this gets tests passing on Win32. > > We might not need *any*. > > [Ignore drive letters for a moment] > The tricky thing about drive letters is that C:foo is a relative path. Unlike unix which has a single cwd, Windows has a cwd per drive and a current work drive. cd c:\foo # Doesn't change current drive, just C:'s current dir. cd d:\bar # Doesn't change current drive, just D:'s current dir. copy c:file d: # copy c:\foo\file d:\bar Win32 API calls and Perl internally accept '/' as a path separator. > VMS Perl accepts Unix pathnames internally. > > The big reason for passing everything through File::Spec is to make native > paths for native tools. But: > > Web browsers have to accept '/' pathnames in URLs. I believe (*please* > check) > that they have to accept '/' pathnames in file URLs. > For all URIs, path segments are separated by "/". Now, I suppose one could stuff the entire file-path into a single URI-path segment, but I've never seen that and "\" would have to be escaped (as it cannot appear in a path segment unescaped). And IIRC drive letters end up munged anyway, as file:///C|/path/goes/here > ":" is now allowed and widely recognised. Apparently, an older URL standard forbade unescaped ":" in path segments. ":" is not allowed unescaped in the first segment of a scheme-less URI, but the provided URI has a scheme, and the drive is never in the first segment. (The first segment is usually empty, but it can also be "." or a server name.) - Eric References: http://www.ietf.org/rfc/rfc3986.txt http://en.wikipedia.org/wiki/File_URI_schemeThread Previous | Thread Next