File Uri Scheme and Relative Files

Question

Assume that the scheme for a uri is "file". Also assume that the path starts with '.'

An example path is './.bashrc'. How would the fulluri look? 'file://./.bashrc' appears odd to me.

Solution 1

In short, a file URL takes the form of:

file://localhost/absolute/path/to/file [ok]

or you can omit the host (but not the slash):

file:///absolute/path/to/file [ok]

but not this:

file://file_at_current_dir [no way]

nor this:

file://./file_at_current_dir [no way]

I just confirmed that via Python's urllib2.urlopen()

More detail from http://en.wikipedia.org/wiki/File_URI_scheme:

"file:///foo.txt" is okay, while "file://foo.txt" is not,
although some interpreters manage to handle the latter

Solution 2

It's impossible to use full file: URI with '.' or '..' segments in path without root part of that path. Whether you use 'file://./.bashrc' or 'file:///./.bashrc' these paths will have no sense. If you want to use a relative link, use it without protocol/authority part:

<a href="./.bashrc">link</a>

If you want to use full URI, you must tell a root relative to which your relative path is:

<a href="file:///home/kindrik/./.bashrc">link</a>

According to RFC 3986

The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy.  They
are intended for use at the beginning of a relative-path reference
(Section 4.2) to indicate relative position within the hierarchical
tree of names.  This is similar to their role within some operating
systems' file directory structures to indicate the current directory
and parent directory, respectively.  However, unlike in a file
system, these dot-segments are only interpreted within the URI path
hierarchy and are removed as part of the resolution process (Section
5.2).

The complete path segments "." and ".." are intended only for use
within relative references (Section 4.1) and are removed as part of
the reference resolution process (Section 5.2).  However, some
deployed implementations incorrectly assume that reference resolution
is not necessary when the reference is already a URI and thus fail to
remove dot-segments when they occur in non-relative paths.  URI
normalizers should remove dot-segments by applying the
remove_dot_segments algorithm to the path, as described in Section 5.2.4.

The complete path segments "." and ".." are intended only for use
within relative references (Section 4.1) and are removed as part of
the reference resolution process (Section 5.2) 

RFC 3986 describes even an algorithm of removing these "." and ".." from URI.

Solution 3

In a terminal you could type "file://$PWD/.bashrc" using "$PWD" to refer to the current directory.

Solution 4

You should not put double slash after file:. Correct form is

'file:.bashrc'

See RFC 3986, path-rootless definition

Solution 5

I don't know your use case.

I have a similar need in my node code, so when I need a file url relative to my working directory I create a url like so ...

const url = "file://" + process.cwd() + "/" + ".bashrc";

View more solutions

Comments

[Cem Kalyoncu]

Is it not also possible to use file:/absolute/path or file:relative (even though this won't work) as you could remove authority for file protocol.

[nilsmagnus]

This works fine for relative paths as well, "file://$PWD/../parentchilddir/somefile.txt"

[Joshua Pinter]

As @kai-dj mentioned in a different answer, if $PWD contains whitespaces like C:/Users/Joshua Pinter/ then the path will not be valid. Needs to be escaped somehow.

[cogmission]

@RayLuo Still doesn't answer question of how to create a URI using relative file syntax of "." ?

[RayLuo]

@cogmission Don't you get the 4th example in my answer? It clearly mentioned there is no way to use "." in URI. Well, you could, it just doesn't make any sense, and won't achieve what you might expect otherwise. You can also refer to the 2nd-highest upvoted answer right in this page. It is longer for you to read and figure out, though.

[Steve Goossens]

You could use variable string substitution, space for escaped space, e.g. file://${PWD// /\\ }/relative/path

[amcgregor]

Please refer to that same RFC, definition of Syntax Components, §3, and §3.2 Authority (describing its relative composition, which involves //), then make note of §2 of the RFC defining the file: scheme which only permits path-absolute. Relative file: URI do not technically exist, even if certain systems allow them by convention.

[amcgregor]

Minor note, backslash escaping is not the correct form. This is a URI. Use percent encoding with the note that space characters themselves can be optimized down to a +. This has the additional note that URI permit UTF-8, so many Unicode characters (such as accented letters, emoji, symbols like §, etc.) actually require no encoding at all. Also of note: unencoded URI will be encoded automatically by user agents, so use as a string (containing spaces) may be a-OK. (Spaces are problems for shell expansion / process argument list building.)

[amcgregor]

§4.2 of RFC3986 says relative references are fine. Canonical process for resolving the reference within a given context ("base URI"). The first "no way" is ignoring the structure of a URI, and is in no way referring to the path. The second is a file named file_at_current_dir at the root of the filesystem. I use Python in this example to really highlight the fact that there is no current directory when building strings.

[RayLuo]

@amcgregor As you quoted, the relative reference in RFC3986 works only within a given context i.e. the "base URI". That condition can be satisfied if it is inside an web page, which uses http:// or https:// scheme. But in a file:// scheme that the OP asks, it semantically depends on where the calling program's CWD is, even if that calling program manages to interpret that URI. In practice, where will you use that file:// uri anyway? If it is a CLI tool, you can completely avoid file:// and just fall back to old school local path. If it is in a browser, we can't assume its CWD either.

[DeusXMachina]

This made the PyLD JSON-LD resolution engine happy when trying to silence this super annoying error: Invalid JSON-LD syntax; @context @id value must be an absolute IRI, a blank node identifier, or a keyword. . I just want a relative ID, let me do that!

[71GA]

What about in VIM?

[1234ru]

@71GA, no idea :/ I don't know vim good enough to answer your question.

[Mohammad Kanan]

Awesome, file:./file.txt for relative path is a fix that works for generic url!

[J. Gwinner]

Actually, loading requirements.txt from Python desperately needs a relative URL. "Old school local path" won't work if you don't know where the program is loaded, and hard coding directory locations on multiple machines and repo's is weird.

[J. Gwinner]

I tried that in a requirements.txt file, and the error that comes back is that ERROR: Invalid requirement: 'apsw @ file:.installPreqs/apsw-3.37.0-cp39-cp39-win_amd64.whl' (from line 2 of requirements.txt). It doesn't work as file:./install ... either.