Absolute path to Relative Path in Unix
but it’s saying I’m not getting the right answer, can anyone give me some hints or explain the differences between a relative path and absolute path, because I still dont under it.
4 Answers 4
Relative is always, well, relative to some existing directory, you are currently «located» in (by means of the cd command, usually). In your question you don’t show what the current directory is. So there is no single «correct» answer.
If your current directory is, say, ~ (which is just a shortcut for your home directory, for example, /home/myuser ), then you’re relative ls command would look like (I’m adding the implied previous cd command for clarity):
cd ~ ls UnixCourse/fileAsst/*.txt likewise if your current directory is ~/UnixCourse , then your relative ls command would look like:
cd ~/UnixCourse ls fileAsst/*.txt or the most simply case, when you are already in the directory you want to list the contents of:
cd ~/UnixCourse/fileAsst ls *.txt Finally, as you have (accidentally, I’d assume) discovered, you can use .. and . in your paths, to imply «one (sub)directory up» or «the current directory».
For example, the following paths are equivalent and all resolve to «UnixCourse/fileAsst»:
UnixCourse/../UnixCourse/fileAsst/ UnixCourse/SomeOtherDir/../fileAsst/ UnixCourse/./fileAsst UnixCourse/fileAsst/YetAnotherDir/../ Note that this is a orthogonal concept and can be used with both, relative and absolute, paths.
There are two classes of pathname:
Absolute pathnames have the same meaning regardless of your current working directory. An absolute pathname might contain .. components after the initial slash. An absolute pathname with no .. components that traverses no symlinks is sometimes known as a ‘real path’, after the system call realpath() that can be used to determine the real path of a name.
Relative pathnames are relative to the current working directory; conceptually, every relative pathname could be deemed to start with ./ . A relative name might start with .. to move upwards from the current working directory. A special case of relative pathname is a simple filename — a name with no explicit directory component. That is a file (or other named object) in the current directory, of course.
To determine a relative pathname from an absolute pathname, you also have to know the current working directory.
How to convert absolute path to relative in c linux
I would like to know how an absolute path of a symbolic link can be converted to relative based on a given directory (that includes the linked file) in c language on linux (Ubuntu) OS. I thought searching for the sub-string of the relative path, but what if it already exists higher in the folder’s hierarchy? Here is a more specific description of what I want to do: Relative path:
/home/giorgos/Desktop/folder/folder1/folder2/a.pdf /home/giorgos/Desktop/myfolder/folder1/folder2/a.pdf /home/giorgos/Desktop/folder/folder/folder/folder1/folder2/a.pdf It can be searched both forwards and backwards and if replaced it still gives a wrong output Only if I knew the relative path I could search the absolute backwards and replace it, then the output would be correct:
/home/giorgos/Desktop/folder/myfolder/folder/folder1/folder2/a.pdf I know of no generic, pre-written code that will do this; what is the context of this problem? There might be a good solution that doesn’t necessarily go this route.
You may be right, I am actually trying to copy a folder and all of its contents to another folder, that includes links and I want them to point on the new folder’s items. Think I should post another question?
I am making a new question as this is a bit general, please help there thanks for all the help I hope I didn’t make a big mess posting two questions onthe same subject I am sorry about it
3 Answers 3
Converting a path to relative is a matter of first seeing how many base atoms are shared between the two paths, and then inserting ../ to navigate backwards up the tree before navigating down the correct branch. IE going from: /foo/bar/some/path to /foo/other/path you’ll first see that they share /foo, to navigate upwards to that point you need 3 ../, turning the relative path into /foo/../../../other/path . There’s a boost::filesystem example for C++ here , save for the C++ & boost::filesystem the same can be done in C.
Still if the paths are like /foo/bar/one/foo and you’re going to foo/bar/one/foo/onemore then you will stop at the first encountered foo. Am I correct?
Nope, you continue on. In the above example if you’re going to go from the first to the second, you’ll see that the entirety of the first is common with the second, so the result is simply onemore . The atoms do not need to be unique across the whole directory tree, it’s the branch in itself that is the UID for the path.
I’d be seriously tempted to make the decision, if I were writing this tool, that absolute symbolic links should have the same value when moved somewhere else in the filesystem — the user wanted a very specific file. And, relative symbolic links should have the same value when moved somewhere else in the filesystem — the user wanted the links to work regardless of where the directory tree was rooted.
But if the two types of links were intermixed, then you’d have some more work to do — which is where I assume you are now. (Unix programs are often not that forgiving about guessing a user’s intent; if you just readlink(2) and symlink(2) exactly what the filesystem says, your program will never be surprising.)
rsync(1) might have some source code you can use — or at least learn from. The —safe-links command line option causes rsync to ignore absolute symbolic links and relative symbolic links that point outside the trees it was instructed to copy. This isn’t canonicalizing paths to relative as you wish but it may provide sufficient code for discovering which links point outside the directory tree in question.
Slightly related; the Linux-specific symlinkat(2) system call may make it easier for you to create your symbolic links. (The family of . at() system calls are something like providing a process with multiple «current working directories» without forcing you to make all the fchdir(2) calls yourself.)