Getting the target of a symbolic link with pathlib

Question

Is there a way to get the target of a symbolic link using pathlib ? I know that this can be done using os.readlink() .

I want to create a dictionary composed by links and their target files.

links = [link for link in root.rglob('*') if link.is_symlink()]
files = [Path(os.readlink(str(pointed_file))) for pointed_file in links]

... and I want to filter all paths that are not absoulute...我想过滤所有不是绝对的路径

    link_table = {link : pointed_file for link, pointed_file in zip(links, files) if pointed_file.is_absolute()}

Answer 1

Update: Python 3.9 introduced Path.readlink() method, so explanations below apply to earlier releases only.

Nope, it's currently not possible to get the results from pathlib that os.readlink() gives. Path.resolve() doesn't work for broken links and either raises FileNotFoundError (Python <3.5) or returns potentially bizarre path (Python 3.6). One can still get old behaviour with Path.resolve(True) , though that means incompatibility between versions (not mentioned in the package documentation nor Porting section of Py3.6 release document by the way).

Also regarding updated question about absolute paths, os.readlink() is the only way to check whether symbolic link is absolute or relative one. Path.relative_to() as name says, transforms existing Path to relative one, without checking whether symbolic link destination path starts with '/' or not. The same applies for Path.is_absolute() . Finally Path.resolve() for existing targets, transforms destination path so it destroys required information on the way.

And by bizarre path above I mean, let's say in /home/test there's symlink .myapp pointing to .config/myapp/config . If .config/myapp doesn't exist and the code is written in Py<=3.5, Path.resolve() would raise an exception and the app could inform a user about the missing file. Now if called from Py3.6 without code changes, it resolves to ~/.config/myapp , the exception is not thrown, so check around .resolve() passes, but then probably another exception will be thrown later when the app will try to open the file for reading, so the user may get message that ~/config/myapp file is not found, though that's not really the one missing here. It may be even worse – when app would do Path('/home/test/.myapp').resolve().open('w') (not necessarily in one step, but let's say as part of some sanitization process), then simply wrong file is created. Of course next time the app is called, path resolves one level deeper, to /home/test/.config/myapp/config (as Path.resolve() doesn't check if myapp is a directory or not), and both reading and writing will fail with a NotADirectoryError exception (with a little misleading "Not a directory: /home/test/.config/myapp/config" as a description…).