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
Related
In LaTeX, the code
\bibliography{/Users/Name/Library/Mobile Documents/com~apple~CloudDocs/Academic/Research/Bibliography/Bib.bib}{}
does not render the reference list. When I use
\bibliography{/Users/Name/Library/Bib.bib}{}
it does. So I thought the problem is the space in "Mobile Documents". Therefore I used
\bibliography{"/Users/Name/Library/Mobile Documents/com~apple~CloudDocs/Academic/Research/Bibliography/Bib.bib"}{}
and it does not work. Where am I making the mistake?
To avoid all possible conflicts with special characters like spaces and ~, you could use a relative path. In your specific case this would mean
\bibliography{../../../Bibliography/Bib}
which means going 3 directories upwards and then into the Bibliography folder.
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".
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.)
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.
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.