When using relative URLs and want to address a file in the same folder we have two options:
Just type a file name:
image1.png
Or this:
./image1.png
I tried these and encountered the same results.
What's the difference between these two? Although the result is the same, is one preferred to another one?
Essentially: there is none.
Both are relative to "the current context", called the base URI in the specification. (With ./ it's explicitly relative to the current context, without it, it's implicitly relative to the current context.) With links in both forms, the browser will perform relative resolution to determine the actual URL to navigate to.
Inclusion of such a prefix is essentially meaningless noise, given the implicit behaviour is explicitly documented, and the explicit form is optional. (It's not wrong, it's just not the optimal—most compact—form.)
Related
I'm working on a custom rule in skylark that is trying to use the proto compiler. Due to intricacies of how it works, I need to split a path into a directory for the external dependency and the path part that is relative to that.
Example1:
File:[/private/var/tmp/_bazel_endobson/c56b77af296477cd0f319aa9d4ce1d19[source]]external/googleapis/google/devtools/build/v1/build_status.proto
I want the paths:
/private/var/tmp/_bazel_endobson/c56b77af296477cd0f319aa9d4ce1d19/external/googleapis/
google/devtools/build/v1/build_status.proto
Example2:
File:[[/private/var/tmp/_bazel_endobson/c56b77af296477cd0f319aa9d4ce1d19/execroot/bes_example]bazel-out/darwin_x86_64-fastbuild/genfiles]external/com_google_protobuf/google/protobuf/any.proto
I want the paths:
/private/var/tmp/_bazel_endobson/c56b77af296477cd0f319aa9d4ce1d19/execroot/bes_example/bazel-out/darwin_x86_64-fastbuild/genfiles/external/com_google_protobuf
google/protobuf/any.proto
The issue is that bazel allows accessing the root and root relative parts of the path, but doesn't give insight into if the path has the 'external/' part or not. The protocol buffer compiler needs this because it needs to know the directories that correspond to the root directories from the user's point of view so that it can use relative paths from the source.
Is there a principled way of detecting this other than hackily looking at the path to see if it has 'external' in it?
I'm afraid I cannot give you a really great answer here :( Eventually, we'd like to remove the "external" path segment, but it hasn't happened yet. The current rule is that you have it for source artifacts, but you don't have it for generated artifacts.
Thus, what I'd do is exactly what you suggest -- check if the first path segment is "external".
This should be pretty simple I need know what dots mean in a url such as "../../../Program Files (x86)/Filed/examples/tmw_desert_spacing.png"
I'm assuming this is some kind of shorthand that means "the same as the current directory"/etc/folder/file.png a link to an article that explains this would be nice too, my google search turned up nothing since im not even sure this is called a url. thanks
more info: the program im writing won't except this as the file name, I need to konw what need to change to become acceptable.
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.
The takeaway is that they have the same meaning as in paths on a linux or windows system - single dot means "the directory specified by the preceding part of the path", two dots mean "the parent directory of the directory specified by the preceding part of
I understand that an absolute path is of the type:
http://www.example.com/thisdir/4/5uy3/2/s.js
and also, that relative paths are of the type:
5uy3/2/s.js (in relation to directory "4")
but what is the term for the type of path that is prepended with a slash to reference back to the root? For example, if someone was working on a script in s.js, he/she might use /thisdir/4/5uy3/2/s.js when including that javascript from different directories to avoid having to consciously think about the current working directory when including it.
Do you know what this type of path is called?
From Dreamweaver / About linking and navigation
There are three types of link paths:
Absolute paths (such as http://www.adobe.com/support/dreamweaver/contents.html).
Document-relative paths (such as dreamweaver/contents.html).
Site root–relative paths (such as /support/dreamweaver/contents.html).
The term "application root" would be the same as "site root" except that the site must be an application.
Consider:
<xsl:result-document
href="{string-join(
($scripts-offset, $metadata-directory, $redirect-file),
'/'
)}"
format="text">
in which the net effect of the string-join is "../resources/foo.txt".
What is this supposed to be relative to? The style sheet? The input document?
EDIT
Cher answerers: after posing this question, I had a burst of energy and coffee and read the spec for xs:result-document carefully, and I also read the implementation of Saxon-B. The spec calls for the href to be relative to the 'primary output document'. Depending on how you call Saxon, it might set that up correctly from the File object you supply it as a target ... or it might require you to make an extra call to set it up. So upvotes all around, and sorry for all the trouble.
This is implementation defined.
From http://www.w3.org/TR/xslt20/#creating-result-trees
The href attribute is optional. The
default value is the zero-length
string. The effective value of the
attribute must be a URI Reference,
which may be absolute or relative.
There may be implementation-defined
restrictions on the form of absolute
URI that may be used, but the
implementation is not required to
enforce any restrictions. Any legal
relative URI must be accepted. Note
that the zero-length string is a legal
relative URI.
The base URI of the document node at
the root of the final result tree is
based on the effective value of the
href attribute. If the effective value
is a relative URI, then it is resolved
relative to the base output URI. If
the implementation provides an API to
access final result trees, then it
must allow a final result tree to be
identified by means of this base URI.
And from http://www.w3.org/TR/xslt20/#dt-base-output-uri
This document does not specify any
application programming interfaces or
other interfaces for initiating a
transformation. This section, however,
describes the information that is
supplied when a transformation is
initiated. Except where otherwise
indicated, the information is
required.
A base output URI. [Definition: The base output URI is a URI to
be used as the base URI when resolving a relative URI allocated to a final
result tree. If the transformation generates more than one final result tree, then typically each one will be allocated a URI relative to this base
URI. ] The way in which a base output URI is established is implementation-defined.
But more important, think about this note:
Note:
The base URI of the final result tree
is not necessarily the same thing as
the URI of its serialized
representation on disk, if any. For
example, a server (or browser client)
might store final result trees only in
memory, or in an internal disk cache.
As long as the processor satisfies
requests for those URIs, it is
irrelevant where they are actually
written on disk, if at all.
In Saxon and AltovaXML it's relative to path from XSLT processor were called. For example:
cd somePath
java -classpath lib\saxon9he.jar net.sf.saxon.Transform -o:output.xml xml\input.xml xsl\stylesheet.xsl
"C:\Program Files (x86)\Altova\AltovaXML2011\AltovaXML.exe" -xslt2 xsl\stylesheet.xsl -in xml\input.xml -out output.xml
In your case it would be:
somePath\..\resources\foo.txt
I have a file that describes input data, which is split into several other files. In my descriptor file, I first give the path A that tells where all the other files are found.
The originator may set either a relative (to location of the descriptor file) or absolute path.
When my program is called, the user gives the name of the descriptor file. It may not be in the current working directory, so the filename B given may also contain directories.
For my program to always find the input files at the right places, I need to combine this information. If the path A given is absolute, I need to just that one. If it is relative, I need to concatenate it to the path B (i.e. directory portion of the filename).
I thought boost::filesystem::complete may do the job for me. Unfortunately, it seems it is not. I also did not understand how to test wether a path given is absolute or not.
Any ideas?
Actually I was quite misguided first but now found the solution myself. When "base" holds the path A, and filename holds B:
boost::filesystem::path basepath(base), filepath(filename);
if (!basepath.is_complete())
basepath = filepath.remove_leaf() /= basepath;
base = basepath.string();
It works with Linux at least (where it would be very easy to do without boost, but oh well..), still have to test with Windows.