I think this demonstrates the problem with the truth-but-not-the-whole-truth. Absolute paths do need to be avoided in source code, to enable the users or their adminstrators to follow their own installation policies rather than have every application that comes along make its own sweet rules for where it is installed and what working directories it uses.

In the well-ordered world of Unix and Linux, shared libraries, applications and even data to some extent, have conventional places to live, many absolute paths are indeed absolutely reliable - but I do say only 'many'.

In particular, a system adminstrator desperately needs the freedom to categorise applications according to a number of considerations, including whether the application is meant to be invoked ad hoc, at user login, or during what level of system startup, which will influence his personal or required choices of installation and working paths.

The standard solution to address all such considerations is to place absolute paths in configuration files which are then either loaded into environment variables, accessible via %ENV, or a perl subroutine may load them directly, early in the execution of an application.

But really conscientious applications will also define all subdirectories in configuration files so that the code is not only 100% free of hard-coded absolute paths but of hard-coded relative paths as well! Even those relative paths will then be computed into absolute paths at run-time and may also be configured by the user without touching the code.