This is not surprising at all.
ls is going to ask "what is
.. in the current directory" which is always the actual parent path.
The only consistent behavior is to always ask the disk what the parent path is. Resolution of a symlink name is only really done through the
$PWD environment variable which is only available in shells and may even be wrong;
chdir won't update it. So one needs to resolve
$PWD fully, see if it matches
getpwd() only then can you even hope to think you have a valid symlink name the user might want to use for that path. All other paths are unknown how one wants to resolve them and the only sensible and consistent thing to do is use absolute paths.
Just for the record, CMake tries to do these symlink-name shenanigans and resolve
$PWD rather than
getpwd() which makes other tools very confused when CMake makes relative paths that assume
$PWD actually works when the disk says you're off in the weeds. For anyone curious, this issue is the task to actually fix this behavior while still supporting the use cases that actually need
I don't think "smart fixing" of broken configuration setups is something users should get beyond "yeah, that doesn't work, try again?".
Well, mount points can relocate, but at that point, you're going to get a completely different name for such a thing if you want that resolved.
There are HPC setups where the user's home directory is
/home/uname -> /mnt/sanXYZ/users/uname where
XYZ can change between reboots because $reasons. Here, the
/home/uname is the stable symlink one should use for such paths and CMake tries its darndest to do so. The problem is that "rewrite realpath name X to symlink name Y" is done way too low-level and means asking CMake for an absolute path of something ends up giving back a symlink name instead. It is also too low-level for CMake to know that resolving a
.. component across these symlink names should instead start looking up the absolute path in order to compute a relative path that actually works when handing it off to another tool.