It appears that that there are two limitations regarding symlinks (at least in Manjaro XFCE).
1) Only absolute (ie. no relative) symlinks can be made from Thunar: When you use Ctrl+Shift drag to make a symlink in Thunar, the symlink created is always absolute. To create a relative symlink you need to use the -r option in the command line (eg. ln -sr <FILE_TO_LINK> <DESTINATION>. It’s not a big issue, but noteworthy because…
2) BIGGER ISSUE: Cannot make a symlink that points to a symlink from the command line: I can trivially do this from Thunar but surprisingly when I attempt this from the command line, ie. ln -sr <SYMLINK> <DESTINATION_SYMLINK> the created link point to what the first symlink points to, instead of pointing to the symlink.
Therefore between 1 and 2 I’m not able to fulfill my use case, which is a relative symlink that points to a symlink.
Wow. You are 100% correct with those instructions for the command! Thanks!
Having said that we don’t know where you got the information that [-r] “resolves”. My manual says:
with -s, create links relative to link location
…which would seem to be incorrect/incomplete manual information. I tried the verbose [--relative] too and it also ‘resolves’ as well! Notice that my manual only differs very slightly from the manual @Nachlese provided above, but it does differ, and even @Nachlese 's description doesn’t mention the added side-effect of ‘resolving’.
In fact nowhere in my manual is ‘resolve/resolving’ discussed.
This would obviously be an upstream issue but perhaps the developers of a possible --resolve (-R ?) option made a mistake and included it in the [-r] option??? Also, I’d write that [-r] flag “actively strips common folders from the provided TARGET and LINK to ensure the resulting link is relative” and put forward the notion that the verbose form of the option should probably be --force-relative not simply --relative because its entirely possible to create relative links without it.
I’ll leave those as exercises for the curious reader/maintainer. PROBLEM SOLVED VIA GUIDANCE. If anyone makes an upstream ticket re above, please link it below. If I’m wrong, do tell me.
Of course you don’t - but, of course, I do.
I’m currently on Linux Mint, and that is what man ln shows me there.
Would not have expected such differences between different versions of the manual pages.
My ln version is:
ln (GNU coreutils) 8.32
Don’t know about the version of the manual page for it.
Your confusion, as demonstrated above, is due to not understanding the use of ‘resolves’ in this context. It refers to the intended result; you could just as easily substitute that for ‘translates as’, ‘results in’, or ‘equals’, for example.
It’s simply word usage, and not meant to describe any specific function of ln. The use of ‘resolves’ is therefore irrelevant to any apparent differences in the manual descriptions.
Because @Nachlese mentioned a more complete manual (via their stated Linux Mint) I did some extra digging online.
To my surprise it turns out there isintended “resolving” being done for relative links although the reasoning is beyond my comprehension at this time. A claim provided is it “gives greater control over relative file name generation” that does quite make sense to me yet, and there is some sort of test using a syntax I’ve not come across so don’t understand.
Basically my man page appears unchanged, still no mention of this “resolving” side-effect and yes the man page says coreutils 9.4, so its definitely the latest.
Does anyone here know what makes “forcing” relative links special here, that they require resolving the symlink? But not when specifying normal symlinks. It so far seems arbitrary to me, but I’m no expert on symlinks.
Thanks yes I know it can be risky, and on second thoughts maybe being coreutils, this is an EXTRA BAD idea. As an aside, I just tried a proper pacman -Syu update and a “could not satisfy dependencies” error “kvantum (1.0.10-2) breaking dependency ‘kvantum-qt5’ required by kvantum-theme-matchama”. Maybe I really have broken something and should timeshift as there is nothing about this error on these forums. I get to approve a bunch of mostly KDE packages moving to the ‘Extras’ repo but after that pacman exits in error. I see that pacman requires coreutils too, may I will timeshift. **Don’t let this distract from the topic though, because…
The code in ln does apparently. I really don’t see what is it to understand here.
And “relative” in this case means (IMHO) relative to the directory where you are putting the symlink in. In other words, when you do ln -rs /some/path/file /some/other/path/link it calculates what is the relative path from /some/path/ to /some/other/path/ so you don’t have to, and by doing so, the code apparently resolves any symlinks too.
Why is it so? Because someone wrote it like that.
I also updated my answer. Now you can check strace, syscalls and source code and write a thesis on symlinks.