File Uri Scheme and Relative Files

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.

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

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][1]

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.

[1]: https://www.rfc-editor.org/rfc/rfc3986 "RFC 3986"

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

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

'file:.bashrc'

See RFC 3986, path-rootless definition

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";

URIs are always absolute (unless they're relative URIs, which is a different beast without a schema). That comes from them being a server-client technology where referencing the server's working directory doesn't make sense. Then again, referencing the file system doesn't make sense in a server-client context either 路. Nevertheless, RFC 8089 permits only absolute paths:

> The path component represents the absolute path to the file in the file system.

However, if I were to postulate a non-standard extension, I would choose the following syntax:

file:file.txt
file:./file.txt

The explanation is that RFC 8089 specifies non-local paths file://<FQDN of host>/path and local paths file:/path, file://localhost/path, and file:///path. Since we're almost certainly trying to specify a local relative path (ie, accessible by "local file system APIs"), and because a . is not a FQDN or even a hostname, the simple file: scheme + scheme-sepecific-part URI syntax makes the most sense.

In a unix shell script I managed to go with this:

file://`pwd`/relative-path

In your particular case:

file://`pwd`/.bashrc