Symlinks to symlinks

[soundofthunder]

@anon51566685

it calculates what is the relative path from

It resolves to the relative path of the symbolic link you’re creating, in this case, yes.

@anon51566685

Now you can check strace, syscalls and source code and write a thesis on symlinks.

I hardly think that’s necessary, when there’s already sufficient documentation: man ln.1 and man ln.1p

Hmm, I thought I was responding to the OP (same colour icon )

[anon51566685]

@soundofthunder

same colour icon

Should buy new monitor. (or eyes)

[soundofthunder]

@anon51566685

Should buy new monitor. (or eyes)

Eyes, methinks

[anon33601770]

@AqitaUnflair

Because @anon33601770 mentioned a more complete manual (via their stated Linux Mint) …

I think the older version was incomplete or even wrong on this point.

recent:

-r, --relative
              with -s, create links relative to link location

-s, --symbolic
              make symbolic links instead of hard links

vs old:

-r, --relative
              create symbolic links relative to link location

-s, --symbolic
              make symbolic links instead of hard links

Without -s, hard links are created, I presume - this was not so explicit in the older version.
But I just read, did not test the behavior or differences between them. I can’t imagine that the behavior actually changed.

[soundofthunder]

Or, maybe this interpretation;-

-r, --relative : creates hard links relative to link location

ln -r

-r With -s, --relative --symbolic : creates symbolic links relative to link location

ln -r -s

-s, --symbolic : creates symbolic links instead of hard links

ln -s

[nikgnomic]

ln invocation (GNU Coreutils 9.5)
‘-r’
‘–relative’

Make symbolic links relative to the link location. This option is only valid with the --symbolic option.

Example:

ln -srv /a/file /tmp
'/tmp/file' -> '../a/file'

Relative symbolic links are generated based on their canonicalized containing directory, and canonicalized targets. I.e., all symbolic links in these file names will be resolved. See realpath: Print the resolved file name., which gives greater control over relative file name generation

[Aragorn]

@AqitaUnflair

“could not satisfy dependencies” error “kvantum (1.0.10-2) breaking dependency ‘kvantum-qt5’ required by kvantum-theme-matchama”.

There are several threads on that already. and the answers are in there.

[AqitaUnflair]

@nikgnomic

Relative symbolic links are generated based on their canonicalized containing directory, and canonicalized targets. I.e., all symbolic links in these file names will be resolved. See realpath: Print the resolved file name., which gives greater control over relative file name generation

Yes I shared that link above and it must be noted that the man page for ln (latest or not) doesn’t mention this resolving which is the main issue. The side issue and curiosity for me is at the end of that sentence:

which gives greater control over relative file name generation, as demonstrated in the following example:

ln--relative() {
  test "$1" = --no-symlinks && { nosym=$1; shift; }
  target="$1";
  test -d "$2" && link="$2/." || link="$2"
  rtarget="$(realpath $nosym -m "$target" \
              --relative-to "$(dirname "$link")")"
  ln -s -v "$rtarget" "$link"
}

Is anyone able to show what is meant above in plain english. I’m just not familiar with some of the syntax, are they trying to say using [-r] is equivalent to using a realpath command to extract the canonical/resolved filepath? If so, how does that help toward “greater control over relative file name generation”? If anything control is taken away. To give greater control the canonicalizing/resolving would be separated out into another option (eg. -c --canonicalize(?) or -R --resolve(?))

As it stands there is an inconsistency here. When making a normal symlink (not relative) there is no canonicalizing, when asking to make a relative symlink, the developers chose to ALSO canonicalize. I’m totally ok with this. Either:

a) this behavior must be documented in the man pages that Manjaro gets, not just for lucky Linux Mint users (on this occasion), it should make clear that relative symlinks can be done manually without -r, as explained by the solution by @anon51566685, or
b) the canonicalizing/resolving is not done for relative symlinks (consistent with normal links) but the option to is separated out to a -c --canonicalize option (an issue for other devs)
c) the canonicalizing/resolving is done for normal symlinks too (consistency) but there is an option to NOT resolve, possibly -R --no-resolve(?) or -C --no-canonicalize(?) (again an issue for other devs)

My preference is simply (a), documentation explaining what is going on and why. I believe resolving was done for convenience/optimization, not greater control, but would love to be proven wrong.

@Aragorn

several threads on [“could not satisfy dependencies” error “kvantum"] already

Sweet, will try search again

[anon51566685]

@AqitaUnflair

a) this behavior must be documented in the man pages that Manjaro gets, not just for lucky Linux Mint users

Please stop dreaming for a second. There is no mention about any resolving anywhere in docs, no matter distro. It’s the word I used. If you want to change docs, then open a new issue at coreutils.

[AqitaUnflair]

@anon33601770

@AqitaUnflair

Having said that we don’t know where you got the information that [-r] “resolves”

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.

This is what we were referring to, wrt documentation.

[nikgnomic]

I posted a link to GNU documentation in post #12 and nobody seemed to have read/understood it, so I reposted link again with a quote in post #26 dealing with original topic question

this behavior must be documented in the man pages that Manjaro gets

/usr/share/man/man1/ln.1.gz is provided by package coreutils, that is inherited from Arch
So if you want changes made to the manpage you would need to contact Arch package maintainer
Arch Linux - coreutils 9.5-1 (x86_64)

IMO the major inconsistency here is that there is no information about the use-case for these symlinks. I suspect that creating relative symbolic links might be the Y part of an XY problem and there may be another way to deal with the underlying X part

[MrLavender]

@AqitaUnflair

this behavior must be documented in the man pages that Manjaro gets

The man page for ln comes unchanged from GNU Coreutils source distribution. If you think there is a bug in that documentation then report it to the GNU Coreutils project.

[soundofthunder]

Pass the salt.

[AqitaUnflair]

Its settled, the a), b), c) proposals with a link to this thread will make it to coreutils. The motivation is obviously to prevent this confusion happening to others. I actaully don’t use email. Is there a good temp email server out there that I can use? Just DM it, no gafam or cloudflare, please. The one I normally would use is down atm and that makes me sad.

[AqitaUnflair]

If anyone is compelled to submit this on my behalf please email the following to bug-coreutils@gnu.org with subject Symlinks to symlinks inconsistency and confusion

Hello, I've submitted this on behalf of someone whose temp email service is not working. They say:

Symlinks that are made with the [-r --relative] option, have the added side-effect of resolving (or canonicalizing). This is not mentioned in the man page, but it *is* mentioned here with a somewhat confusing code example that is supposed to show how the side-effect gives "greater control" to the user.

https://www.gnu.org/software/coreutils/manual/html_node/ln-invocation.html

Please see this thread as to how I, as a hobbyist (gnu)linux user and privacy advocate, struggled.

https://forum.manjaro.org/t/symlinks-to-symlinks/149596

No one in the forum was able to explain the benefit of this inconsistent side-effect.

There are three ways to resolve this:

a) this behavior be documented in the man page, making clear that relative symlinks can be done manually without -r, as explained by the solution in the forum thread,

b) the canonicalizing/resolving is not done for relative symlinks (consistent with normal links) but the option to is separated out to a -c --canonicalize(?) option, or

c) the canonicalizing/resolving is done for normal symlinks too (consistency) but there is an option to NOT resolve, possibly -R --no-resolve(?) or -C --no-canonicalize(?)

My preference is simply (a), documentation explaining what is going on and why. I believe resolving was done for convenience/optimization, not "greater control", but would love to be proven wrong. :)

A --no-canonicalize -C flag makes sense if we want the --relative option to be useful in more use-cases but that is almost a feature request, rather than a bug. 

Thanks greatly for your work
Aqita

[soundofthunder]

@AqitaUnflair

If anyone is compelled to submit this on my behalf

[AqitaUnflair]

What’s the problem?

[soundofthunder]

@AqitaUnflair

What’s the problem?

Your analysis makes me dizzy.

[AqitaUnflair]

@soundofthunder

Your analysis makes me dizzy.

Np, @soundofthunder. To simplify…:

a) fix man page, or
b) and c) are about altering the behavior for consistency, regarding either b) creating relative symlinks (to match what I might call “absolute symlink” creation), or c) altering the making of “absolute” ones (to match ‘relative’).

Finally I suggest adding a helpful --no-canonicalize option to extend functionality of the --relative option to suit the simple symlink-to-symlink use-case.

Please tell us when above is emailed to coreutils@gnu.org, I’m sure that they will understand and appreciate it.

[MrLavender]

@AqitaUnflair

Please tell us when above is emailed to coreutils@gnu.org, I’m sure that they will understand and appreciate it.

I’m sorry but no-one is going to do that for you. You’re the one with the problem, you report it.