[Post-Install] ls -l adding spurious white space

[jlittle]

This is an odd one. ls -l is misbehaving, adding spaces between the ACL indicator (the "+") and the link number, proportional to the number of files displayed. For example:

$ ls -ld b*
drwxrwxr-x+      1 john john     0 Nov 19  2024 bdir
drwxrwxr-x+      1 john john  3066 Apr 27 09:11 bin
drwxrwxr-x+      1 john john   108 Feb 16 10:10 bion
-rw-rw-r--+      1 john john  5336 Feb 12 12:55 borders.txt
drwxrwxr-x+      1 john john   206 May 16  2024 btrview
drwxrwxr-x+      1 john john   914 Apr 28 07:35 build
drwxrwxr-x+      1 john john   550 Oct 28  2024 bus
$ ls -ld [a-d]*
drwxrwxr-x+                 1 john john   570 Jan 10 17:04 adventure
drwxrwxr-x+                 1 john john   114 Nov 20  2022 apod.d
drwxrwxr-x+                 1 john john     0 Nov 19  2024 bdir
drwxrwxr-x+                 1 john john  3066 Apr 27 09:11 bin
drwxrwxr-x+                 1 john john   108 Feb 16 10:10 bion
-rw-rw-r--+                 1 john john  5336 Feb 12 12:55 borders.txt
drwxrwxr-x+                 1 john john   206 May 16  2024 btrview
drwxrwxr-x+                 1 john john   914 Apr 28 07:35 build
drwxrwxr-x+                 1 john john   550 Oct 28  2024 bus
drwxrwxr-x+                 1 john john   394 May 11 22:38 canberra
drwxr-x---+                 1 john john    54 Oct 13  2025 catherine
drwxrwxr-x+                 1 john john     0 Oct 21  2025 clare
-rw-rw-r--+                 1 john john 33872 Mar 29 17:49 d.png
-rw-rw-r--+                 1 john john   110 Dec 31 16:46 d.txt
drwxrwxr-x+                 1 john john   490 Jul 26  2024 dc
drwxrwxr-x+                 1 john john   268 Jan 1  10:26 desktop
drwxr-xr-x+                 1 john john  3278 May 5  08:08 documents
drwxr-xr-x+                 1 john john  4432 May 17 13:37 downloads

If there are 100 files, there are 100 spaces, making the display a mess. It only happens if the listed directory is the current directory; cd;ls -l shows 70 files with 70 spaces, but ls -l ~ is normal. cd /usr/bin;ls -l has 4478 files and each line has 4478 spaces, about 20 MB of output.

I've undefined any aliases. The same with bash or zsh or dash. dir -l has the same behaviour. konsole or xterm the same. Reducing the environment to a minimum has no effect. Logging on as another, uncustomized user still has the problem.

[Schwarzer Kater]

Sorry, have no time at all to reproduce this now (perhaps later)…
But did you try an alternative like using eza instead of ls as a quick temporary workaround?

[claydoh]

Is ls from gnu-coreutils, or rust-coreutils (or is it uutils-coreutils?)?

In any case, iirc you should have both versions, with the gnu one at /bin/gnuls

Worth a bug report, which I did not see with a quick check.

[Snowhog]

This is not happening on my recently upgraded to 26.04. ls -l behaves correctly.

dpkg -S $(which ls) reports:

coreutils-from-uutils: /usr/bin/ls

[oshunluvr]

Not happening here either. Try a different user account?

[jlittle]

Is ls from gnu-coreutils, or rust-coreutils (or is it uutils-coreutils?)?

In any case, iirc you should have both versions, with the gnu one at /bin/gnuls

Thank you, gnuls does not have the problem.

[jlittle]

Not happening here either. Try a different user account?

I tried that, and the problem reproduces with the other user.

I should also have added that the problem is on my main desktop. Two other installs, a media tiny PC and a VPS, both 26.04, do not have the problem.

[jlittle]

It's the ACL indicator. Try this:

$ mkdir scratch
$ cd scratch
$ touch x y z
$ ls -l
-rw-rw-r-- 1 johnl johnl 0 May 21 10:47 x
-rw-rw-r-- 1 johnl johnl 0 May 21 10:47 y
-rw-rw-r-- 1 johnl johnl 0 May 21 10:47 z
$ setfacl -m u:guest:w x y z
$ ls -l
-rw-rw-r--+   1 johnl johnl 0 May 21 10:47 x
-rw-rw-r--+   1 johnl johnl 0 May 21 10:47 y
-rw-rw-r--+   1 johnl johnl 0 May 21 10:47 z

Note the extra spaces.
Back on my desktop, I can't get rid of the ACL indicator. setfacl -b has no effect.

[jlittle]

It's a known bug, already fixed: https://github.com/uutils/coreutils/issues/10980

IMO not good if something as basic as ls -l gets broken. Till the fix arrives I'll use gnuls.

[Schwarzer Kater]

You are absolutely right (and I can confirm the bug of coreutils-from-uutils: /usr/bin/ls in Kubuntu 26.04 LTS).
And it is good that gnuls solves that problem for the time being…

A practical temporary solution until the bug fix arrives in Kubuntu 26.06 LTS (instead of always typing gnuls in place of ls) could be to define an alias in ~/.bash_aliases:

# replace ls with gnuls
alias ls='gnuls'

and restart your terminal editor (e.g. Konsole).

One could do this by hand (e.g. with nano or Kate)
or in Konsole:
echo -e "\n# replace ls with gnuls\nalias ls='gnuls'" | tee -a $HOME/.bash_aliases


My preferred alternative still is eza.

[jlittle]

Thank you. As I have a number of ls aliases I've gone the hacky route of linking /bin/ls and /usr/bin/ls to gnuls. I'll have to undo that, and possibly redo it, when updates affecting ls arrive.

Having seen other recommendations for eza I'll be checking it out. Into my 5th decade with typing ls there is some inertia.

[Schwarzer Kater]

[…]
Having seen other recommendations for eza I'll be checking it out. Into my 5th decade with typing ls there is some inertia.

Inertia is what aliases are for, aren't they? And why I have not been able to get used to l instead of ls.

alias ls="eza -F --color=auto --group-directories-first"
alias la="eza -aF --color=auto --group-directories-first"
alias ll="eza -lgbhF --color=auto --group-directories-first"
alias lla="eza -algbhF --color=auto --group-directories-first"​