Summary: | 'ln -sr' always dereference target | ||||||
---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | led | ||||
Component: | coreutils | Assignee: | placeholder <placeholder> | ||||
Status: | CLOSED WONTFIX | QA Contact: | qa-sisyphus | ||||
Severity: | normal | ||||||
Priority: | P3 | CC: | evg, glebfm, ldv, mike, placeholder | ||||
Version: | unstable | ||||||
Hardware: | all | ||||||
OS: | Linux | ||||||
Attachments: |
|
ping I forwarded this to coreutils mailing list and received a reply: http://lists.gnu.org/archive/html/coreutils/2013-07/msg00053.html In short, the issue was already discussed at http://lists.gnu.org/archive/html/coreutils/2012-02/msg00167.html, "ln -rs" is not going to change anyway, and even the change to "ln -Prs" is unlikely to be accepted because of ambiguity. For greater control, they suggest using realpath(1) in conjunction with ln(1) without -r. wontfix upstream |
Created attachment 5860 [details] fix 'ln --relative' for no dereference target by default $ ln -sr /etc/X11/lib64/libGL.so.1 /tmp/libGL.so.1 $ readlink /tmp/libGL.so.1 ../usr/lib64/X11/libGL.so.1.2 что вовсе не то, предполагалось. Т.е. '-r' всегда работает, как будто присутсвует '-L' Приложенный патч вроде бы решает это, делая dereference для target только если указан '-L'