ls --dired reports wrong filename boundaries for symlinks

[dcolascione]

Description

ls --dired incorrectly reports filename boundaries that include the symlink target in the //DIRED// output. GNU coreutils correctly reports only the symlink name.

Reproduction

test_dir=$(mktemp -d)
ln -s "./bar/baz" "$test_dir/foo"
ls --dired -la "$test_dir"
rm -rf "$test_dir"

Expected (GNU coreutils 9.1)

  lrwxrwxrwx  1 user user     9 Jan 14 14:18 foo -> ./bar/baz
//DIRED// 60 61 111 113 163 166

The symlink entry 163 166 spans 3 characters = "foo" (correct).

Actual (uutils 0.2.2)

  lrwxrwxrwx  1 user user     9 Jan 14 14:18 foo -> ./bar/baz
//DIRED// 58 59 108 110 159 175

The symlink entry 159 175 spans 16 characters = "foo -> ./bar/baz" (incorrect - includes target).

Impact

This breaks Emacs dired mode. The dired-filename text property gets set to include the symlink target, causing dired-get-filename to return "foo -> ./bar/baz" instead of just "foo".

[ChrisDryden]

Validated that this is still an issue in the latest version of main. in display_item_name we somehow need to store the length of the dired_len and pass it back as part of the function. Its a bit messy to return that as a tuple but theres not another straightforward approach of how to get this value correctly.

[rpatterson]

For those looking for a workaround until this is fixed, I ended up using an alternative:

# update-alternatives --install "/usr/bin/ls" "ls" "/usr/bin/gnuls" "900"

Since Ubuntu, I assume from Debian, has gone to the trouble to make it possible not only to install both the GNU and uutils packages side-by-side (gnu-coreutils and rust-coreutils), but also to choose which the system uses (coreutils-from-uutils and coreutils-from-gnu), it's disappointing that they then put a hard dependency on coreutils-from-uutils in build-essential. That means switching it out is only possible with # aptitude install coreutils-from-gnu coreutils-from-uutils- build-essential- and removing build-essential is a non-starter, too many other common tasks and processes install build-essential which then will likely undo the workaround too soon. I was debating whether to use an alternative for just $ ls anyways, so I'm not sure I wouldn't have chosen that option regardless, just seems weird to support that flexibility in the packaging and then undercut it.

[sylvestre]

@rpatterson this is for an Ubuntu discussion, not uutils ;)