{"id":40,"date":"2021-01-12T09:03:37","date_gmt":"2021-01-12T09:03:37","guid":{"rendered":"https:\/\/veltzer.net:8890\/?p=40"},"modified":"2021-01-12T09:03:37","modified_gmt":"2021-01-12T09:03:37","slug":"finding-broken-symbolic-links","status":"publish","type":"post","link":"https:\/\/veltzer.net:8890\/finding-broken-symbolic-links\/","title":{"rendered":"Finding broken symbolic links"},"content":{"rendered":"\n
I sometimes need to find all broken symbolic links in a folder, recursively or not. Some solutions involve sending the output of Other solutions involve doing My solution is this:<\/p>\n\n\n\n I sometimes need to find all broken symbolic links in a folder, recursively or not. find(1) is the all UNIX right tool for the job as far as finding files is concerned but it does not have an explicit -and -type brokenlink option\u2026 Some solutions involve sending the output of find(1) to some other tool. … <\/p>\nfind(1)<\/code> is the all UNIX right tool for the job as far as finding files is concerned but it does not have an explicit
-and -type brokenlink<\/code> option\u2026<\/p>\n\n\n\n
find(1)<\/code> to some other tool. These solutions are sub-optimal in that once you leave the comfort of
find(1)<\/code> you give up the ability to use many of it\u2019s fine features and run into other problems (file names with white space characters just to name one such problem).<\/p>\n\n\n\n
find -L . -type l<\/code> which forces
find(1)<\/code> to follow all symbolic links and ultimately only print those which it cannot follow. This solution has other drawbacks. One is that you do not necessarily want
find(1)<\/code> to follow every symbolic link since this may cause it to wander to huge areas of your hard drive that you do not wish to scan. Another deficiency is the fact that there is a difference between a symbolic link that cannot be followed and one which cannot be read.<\/p>\n\n\n\n
find . -type l -and -not -exec test -e {} \\; -print<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"