1

I had given an answer on SO, the question was concerning a problem with a relative path. My answer was to use an absolute path, which I thought seemed simpler. The asker claimed to need a relative path, but I couldn't tell why.

It seems reasonable that if you know to go to ../../../foo/bar/, then you would also know to go to /home/willie/foo/bar/.

I can't think of a situation which requires relative paths except in a build script. Are there others I'm not thinking of? Is it bad practice to use one or the other in any situation?

Sorry if this question is off topic, all my googling yielded was how to use them rather than why.

Will
  • 131

1 Answers1

2

I can't think of a situation which requires relative paths

A possible reason to use relative path would be to use paths related to the location of the executable (and not to the current work directory); e.g. if your executable sits in /home/will/bin/foo you would use /home/will/bin/../data/resource (which is /home/will/data/resource) for some resource files. See this answer for details.

Then, you could ship a file tree (e.g. a .tar archive) containing the executable (with some relative paths like bin/foo for the executable and data/resource for resources used by it), your user would install it at any place he likes (e.g. under /home/will/, or /home/joe/soft/ or /opt/ ...) and be able to run the executables and access resources.

This practice is not very common (IIRC, xemacs used it), because most systems have conventions about files, like the Filesystem Hierarchy Standard & hier(7) and software gets installed (e.g. by some make install step) there.