GNU bug report logs - #36666
Minor bug/inconsistency in ls command

Previous Next

Package: coreutils;

Reported by: hoffelmann <at> gmail.com

Date: Mon, 15 Jul 2019 13:53:02 UTC

Severity: normal

To reply to this bug, email your comments to 36666 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#36666; Package coreutils. (Mon, 15 Jul 2019 13:53:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to hoffelmann <at> gmail.com:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Mon, 15 Jul 2019 13:53:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: hoffelmann <at> gmail.com
To: bug-coreutils <at> gnu.org
Subject: Minor bug/inconsistency in ls command
Date: Mon, 15 Jul 2019 09:01:42 +0200
Hi,

I am using ls from the cureutils 8.31 on arch linux (5.2.0 x86_64) and
think it has a bug/inconsistant in printing an file type indicator (-F) 
while using the long listing format (-l).


If I use `ls -F ~` I get the following output:
-----------------------------------------------------------------------
Desktop/    Downloads/	Nextcloud/  Pictures/  Templates/  Workspace/
Documents/  Music@	OneDrive/   Public/    Videos/


As the Music directory in ~ is a symbolic link to another folder an @
is appended.


But when using `ls -Fl ~` the output is
-----------------------------------------------------------------------
total 40
drwxr-xr-x  2 rxo users 4096  8. Jul 07:34 Desktop/
drwxr-xr-x  2 rxo users 4096  1. Jun 11:44 Documents/
drwxr-xr-x  5 rxo users 4096 12. Jul 12:04 Downloads/
lrwxrwxrwx  1 rxo users   15  8. Jul 08:07 Music -> OneDrive/Music//
drwxr-xr-x 19 rxo users 4096  9. Jul 15:00 Nextcloud/
drwxr-xr-x  6 rxo users 4096 18. Jun 14:45 OneDrive/
drwxr-xr-x  3 rxo users 4096 11. Jul 13:30 Pictures/
drwxr-xr-x  2 rxo users 4096 10. Jul 16:01 Public/
drwxr-xr-x  2 rxo users 4096 10. Jul 16:01 Templates/
drwxr-xr-x  2 rxo users 4096 10. Jul 16:01 Videos/
drwxr-xr-x 17 rho users 4096 10. Jul 14:58 Workspace/


As you can see the @ symbol is missing and instead there is an
additional "/" appended to the corresponding entry. I think this is
inconsistant and confusing. 

I would expect to see this line:
-----------------------------------------------------------------------
lrwxrwxrwx  1 rxo users   15  8. Jul 08:07 Music@ -> OneDrive/Music/


or alternatively:
-----------------------------------------------------------------------
lrwxrwxrwx  1 rxo users   15  8. Jul 08:07 Music -> OneDrive/Music/@


but I would prefer the first suggestion.





Information forwarded to bug-coreutils <at> gnu.org:
bug#36666; Package coreutils. (Tue, 16 Jul 2019 08:31:01 GMT) Full text and rfc822 format available.

Message #8 received at 36666 <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: hoffelmann <at> gmail.com
Cc: 36666 <at> debbugs.gnu.org
Subject: Re: bug#36666: Minor bug/inconsistency in ls command
Date: Tue, 16 Jul 2019 01:30:14 -0700
On 2019/07/15 00:01, hoffelmann <at> gmail.com wrote:
> Hi,
>
> I am using ls from the cureutils 8.31 on arch linux (5.2.0 x86_64) and
> think it has a bug/inconsistant in printing an file type indicator (-F) 
> while using the long listing format (-l).
>
>
> If I use `ls -F ~` I get the following output:
> -----------------------------------------------------------------------
> Desktop/    Downloads/	Nextcloud/  Pictures/  Templates/  Workspace/
> Documents/  Music@	OneDrive/   Public/    Videos/
>
>
> As the Music directory in ~ is a symbolic link to another folder an @
> is appended.
>
>
> But when using `ls -Fl ~` the output is
> -----------------------------------------------------------------------
> lrwxrwxrwx  1 rxo users   15  8. Jul 08:07 Music -> OneDrive/Music//
>   
----
In this case, ls -Fl is showing you the result of the link expansion and
the focus is on the 'target', i.e., the OneDrive/Music.  The classifier
character is being shown only for the target -- not the source of the
symlink.

In a different way, in the top listing the '@' in the 1st ls is telling
you that
Music is a symlink, in the 2nd listing, the '->' tells you that the same
thing,
that Music was(is) a symlink, so the '@' would be superfluous.  Instead,
it puts
a classifier on the target so you know what type it is.

One could think of it as inconsistent -- but only if remembering that
inconsistent options (different options) were given as well.


 




This bug report was last modified 5 years and 340 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.