In 26.04, the manual for ln is damaged

In Ubuntu 26.04, both Desktop and Server, the manual for ln is messed up. I’ve checked on three different systems.

Enter man ln to show the problem.

On 24.04, which is correct, the beginning looks like this:

LN(1)                            User Commands                           LN(1)

NAME
       ln - make links between files

SYNOPSIS
       ln [OPTION]... [-T] TARGET LINK_NAME
       ln [OPTION]... TARGET
       ln [OPTION]... TARGET... DIRECTORY
       ln [OPTION]... -t DIRECTORY TARGET...

DESCRIPTION
       In  the  1st form, create a link to TARGET with the name LINK_NAME.  In
       the 2nd form, create a link to TARGET in the current directory.  In the

But on 26.04, the beginning looks like this:

LN(1)                       General Commands Manual                       LN(1)

NAME
       ln - Make links between files.

SYNOPSIS
       ln  [--backup]  [-b  ] [-f|--force] [-i|--interactive] [-n|--no-derefer‐
       ence]  [-L|--logical]  [-P|--physical]   [-s|--symbolic]   [-S|--suffix]
       [-t|--target-directory]    [-T|--no-target-directory]    [-r|--relative]
       [-v|--verbose] [-h|--help] [-V|--version] <files>

DESCRIPTION
       Make links between files.

… and the ending has an “EXTRA” section that looks like the “DESCRIPTION” in 24.04:

EXTRA
       In  the  1st  form, create a link to TARGET with the name LINK_NAME.  In
       the 2nd form, create a link to TARGET in the current directory.  In  the
<snip>

It seems to have been corrupted by something else — but by what? I wonder if that something else is also corrupted!

I checked Ubuntu’s online manual (it’s suffering from the MTU 1500/1320 problem right now). It’s the same there: the 24.04 version is correct, while the 26.04 version is corrupted. Interestingly, the 26.10 version is correct.

This might seem a small thing, but for people wishing to revise how ln works (which includes me, far too often!), this is unusable. It’s also worrying; as mentioned, might other entries have been corrupted?

As this is an LTS version, I imagine that I should report this as a minor bug on Launchpad, but what package do I report it under?

The 26.04 ln manpage is from rust-coreutils while 24.04 and 26.10 are from gnu-coreutils. Apparently the rust-coreutils ln manpage is just not as well written as the gnu-coreutil version.

1 Like

ubuntu-bug rust-coreutils is where I would consider reporting it.

1 Like

26.10 back to gnu-coreutils from rust-coreutils?

1 Like

Any idea why they are even different? Surely they should have been unchanged?

Unfortunately (this is the second time this has happened to me), it gets stuck on collecting information.

How else can I report this bug?

Hi Paddy,

You must radiate some super powerful energy around your desk if even Apport gets intimidated and freezes when sending reports! :grinning_face:

The Apport GUI often hangs when collecting large system logs or when network requests time out. You can bypass the GUI collector completely by filing the bug directly through the web form at https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+filebug

Alternatively, you can run the text-mode client from your terminal with apport-cli -f -p rust-coreutils. That avoids the GUI freeze and walks you through the submission step by step :wink:

3 Likes

Thank you for all your help, Viktor.

I have filed the bug report:

4 Likes

The man page is not “corrupted” or “damaged” in any meaning of these English words I am familiar with. This is exactly what uutils-coreutils creates, so it works as designed. If you believe these man pages are not useable, you really need to address it upstream.

That particular one isn’t usable. It’s not only badly readable, but also it’s wrong.

They’re from separate projects so different people are writing the manpages. Since GNU has been around much longer with a much wider contributor base, the gnu-coreutils manpages have benefited from years of edits to improve conciseness and readability.

If you have gnu-coreutils installed on 26.04, you can invoke the gnu ln manpage with “gnuln” or change the ln symbolic link in /usr/share/man/man1/ from rust-ln.1.gz to gnuln.1.gz

1 Like

Paddy is right - hiding standard ln syntax inside an EXTRA section is definitely a bug, so the bug report makes total sense… for now just use man gnuln …