Is it a good practice that links should always point to absolute path rather than pointing from current directory?
I am talking this with reference - where i need to maintain software and all its previous versions should always point to latest version.
Define "good practice". Whether a link points to an absolute path or not depends on the relationship between the files.
If the files are always in the same relative positions, but could be moved around (eg aliases in bin/), they should be relative. If the actual file is in a known location (eg, you want to link a default config file to ~/.config), then use an absolute path.
Depends on what you want to do. My Linux system has both kinds of symlinks.
find /usr /bin /lib -type l -print0 | xargs -0 ls -ld | less
I don't think there's a "good practice" for that. There are different use cases.
For example if I store a tree with a program installed locally in /home/.../application, I may want to symlink "default config" to some specific config without an absolute path. That way, when I move the whole tree to /home/.../application-other-instance, the link to the config file stays correct.
On the other hand, if I want to reference some global file in /etc/... in a local dir, I will do it with an absolute path symlink. That guarantees that I'm pointing to the same file anywhere I move.
Just think what do you want to achieve, and the relative / absolute path decision will be either obvious, or irrelevant. Only "never do that" rule is probably: Never link to anything in root dir /xxx, via ../../../../../../../xxx
I don't think I can agree with that as a generalization.
There are definitely cases where a relative link makes more sense. With a directory tree of a project, for example. If the project is backed-up, or moved (even duplicated) into another place, absolute links could be confusing and/or disastrous.
Even if you are talking about system-wide tools, there will be cases where relative links make sense, and other times not. Compare having a link to a very generic tool, like grep , versus something like multiple versions and target flavors of the gnu compiler tools living on the same host. In the latter case, absolute links to the specific tool versions will probably required.
It all comes back to what you really want to do in each case. The general answer is that there is no generalized answer.
Related
When changing directories and traversing filepaths, I noticed that sometimes users apply cd foo/bar/ and sometimes cd foo/bar.
I was wondering what the difference was, if any? I presume there's no difference in the context of simply changing directories, but are there consequences of using each method elsewhere?
You're right, there is no difference when changing directories on the command line. You're also right in presuming there is no difference between:
file/path/example/ and file/path/example in other contexts too (where example represents a folder).
Under many, most, or maybe all Unix file systems, if you iterate over the links in a directory, there will usually/always be at least two, one pointing to the current directory ("./"), and one back-pointing to the parent directory ("../"). Except maybe for the root, which would have only the first of these two links.
But it might be that this is not true under some other file systems that purport to comport with most Unix conventions (but don't quite).
Is there a directory somewhere in a Unix file system guaranteed to always be an empty directory and whose link count can always be read using, e.g., stat() or equivalent?
If so, one can check the link count and expect it to be 2. Or perhaps something else, which would allow a program to adjust its behavior accordingly.
There is no standard directory which is always empty -- but you could create one, if you needed to. One easy way to do this would be using the mkdtemp() function.
However, there is no guarantee that all directories will be using the same file system. For instance, if a FAT filesystem is mounted, directories corresponding to that file system may behave differently from other ones.
I am learning the linux utility find and am finding the man page difficult to read. I have defaulted to testing the command and seeing what it does.
I have a file called creek.jpg on my desktop.
When I type
find ~/Desktop creek.jpg
It appears to print out every file in my desktop, then prints out
find: creek.jpg: No such file or directory
Here is my mental picture of how find is working. In the man page, it says finds job is to "walk a file hierarchy." Here is my mental image of how find works. A file hierarchy (also referred to in the man page as a directory tree.) is like an oak tree. Each fork in the tree is a directory. Each leaf or acorn on the tree is a file. Find is a hyperactive squirrel that scrambles up and down the tree, touching every leaf, acorn, and branch.
Since the first line of the man page says that find's job is to walk a file hierarchy, apparently find's main job is to not, as I first thought, to actually find stuff. Instead, its job is to scramble up and down the tree, visiting things. A side effect of visiting things is that you can tell it to look for things and it will tell you if it sees them.
Apparently I am failing at two parts: how to tell it to look for creek.jpg on my desktop, and how to tell it to NOT tell me about every last little branch and leaf it touches with it's excited squirrely paws.
So:
When I type the above command, why is it telling me everything it is visiting, and why is it telling me it did NOT find creek.jpg?
How do I get it to find creek.jpg?
How do I get it to NOT tell me every other file it visited on it's "walk of the file hierarchy"?
You have provided two paths (~/Desktop and creek.jpg in current folder) and haven't provided any matching criteria. Try
find ~/Desktop -name creek.jpg
Try this: find ~/Desktop -name filename
i have this tree structure:
repository/modules/module1
repository/modules/module2
repository/modules/module..
repository/apps/application1
repository/apps/application2
repository/apps/application..
where the applications are using some modules.
now, I'd like to put some resources inside a module (like a very colorfull icons inside a widget used by several applications) but.. something gets wrong.
inside the module CMakeLists.txt if I use only:
set(${MODULE_NAME}_RCS
colors.qrc
)
...
qt4_add_resources (${MODULE_NAME}_RHEADERS ${${MODULE_NAME}_RCS})
no qrc_colors.cxx are created anywhere. so I've tried to add:
ADD_EXECUTABLE (${MODULE_NAME}
${${MODULE_NAME}_RHEADERS}
)
but.. I get this weird error:
CMake Error at repo/modules/ColorModule/CMakeLists.txt:51 (ADD_EXECUTABLE):
add_executable cannot create target "ColorModule" because another
target with the same name already exists. The existing target is a static
library created in source directory
"repo/modules/ColorModule". See documentation for
policy CMP0002 for more details.
(I've changed the path of the error of course)
so.. don't know what to think because i'm new both to cmake and qt..
what can i try?
EDIT:
if I add the ${MODULE_NAME}_RHEADERS and ${MODULE_NAME}_RCS in the add_library command the qrc_colors.cxx is created BUT it is in repository/modules/module1/built and not copied in the application built directory...
There is at least two errors in your code.
1) It is usually not necessary to use ${MODULE_NAME} everywhere like that, just "MODULE_NAME". You can see that the difference is the raw string vs. variable. It is usually recommended to avoid double variable value dereference if possible.
2) More importantly, you seem to be setting ${MODULE_NAME} in more than one executable place, which is "ColorModule" according to the error output. You should have individual executable names for different binaries.
Also, the resource file focus is a bit of red herring in here. There are several other issues with your project.
You can cmake files as CmakeLists.txt instead of CMakeLists.txt which inherently causes issues on case sensitive systes as my Linux box.
You use Findfoo.cmake, and find_package(foo) for that matter, rather than the usual FindFoo.cmake convention alongside find_package(Foo).
Your FindFoo.cmake is quite odd, and you should probably be rewritten.
Most importantly, you should use config files rather than find modules.
Documentation and examples can be found at these places:
http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem
When you would like use a find module, you need to have that at hand already. That will tell you what to look for, where things are, or if they are not anywhere where necessary. It is not something that you should write. You should just reuse existing ones for those projects that are not using cmake, and hence the find modules are added separately.
It is a bit like putting the treasure map just next to the treasure. Do you understand the irony? :) Once you find the map, you would automatically have the treasure as well. i.e. you would not look for it anymore.
For local testing the url is something like:
http://localhost:29234/default.aspx
For staging, the app is in a virtual directory:
http://stage/OurApp/default.aspx
For production, it's the root
http://www.ourcompany.com/default.aspx
However, sometimes we need to do a redirect to a particular directory. We don't always know exactly where we are at.
So, how would I do a redirect to say /subdir1/mypage.aspx?
MORE INFO
I neglected an important item. This url is sent back to the browser so that some javascript code can perform the redirect. (Odd, I know). So a regular ResolveUrl("~/pagename.aspx") won't give the full info...
UPDATE 2
I ended up with the following, which seems to work across the board... It looks a little ugly though.
StringBuilder buildUrl = new StringBuilder(#"http://");
buildUrl.Append(Request.Url.Host);
if (Request.Url.Port != 80) {
buildUrl.Append(":");
buildUrl.Append(Request.Url.Port.ToString());
}
buildUrl.Append(this.ResolveUrl("~/Pages/Customers.aspx"));
buildUrl.Append(String.Format("?AccountId={0}&tabName=Tab2&primaryCustomerId={1}", acctId, custId));
When paths start diverging between different environments, and you cannot bring any sanity to the situation, it's time to start puttin' paths in the web.config.
It's not a cure for inconsistent file paths, but it'll make your code consistent and you won't have to worry about having "let's figure out where i am" logic.
The tilde is a shortcut for HttpRuntime.AppDomainAppVirtualPath (more)
~/subdir1/mypage.aspx
If the subdir1 is a directory within your web application, you can use a relative link (subdir1/mypage.aspx instead of /subdir/mypage.aspx -- note the lack of the first forward slash). This way, it won't matter where your application is because the links will be relative to the current page.
A suggestion is you can use the BASE tag for the page which can be the root. by using this, all your relative paths will be resolved based on BASE path.
General Advice
I recommend storing the path in your settings. There are reasons why some of our projects need various paths and urls, and we can't always get away with using the tilde (~).
Our Strategy
In our projects here at Inntec, our web.config contains a database connection string and a variable saying what the environment is - Production, Staging, Development, etc.
Then, in the database, we've got a set of variables for each environment, and there's a nice class that strongly types the settings and pulls/caches the right setting for the current environment. So in our code we can say: Settings.AppUrl and everything just works.
We use Redgate's Sql Data Compare to sync the settings across all instances (so each environments always has the settings for all environments), and there are unit tests that make sure each environment has a complete batch of settings.
That's one way to do it... So far it has worked really well for us.