GNU bug report logs - #17878
Possible bug in GNU ls with -R

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17878 in the body.
You can then email your comments to 17878 AT debbugs.gnu.org in the normal way.

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

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

From: fuz <at> fuz.su
To: bug-coreutils <at> gnu.org
Subject: Possible bug in GNU ls with -R
Date: Sun, 29 Jun 2014 20:06:30 +0200

I think I found behavior in GNU ls that deviates from the behavior
specified by POSIX.1 2008:

If GNU ls is called on one directory without subdirectories with the
option -R, it prints a directory heading like this:

    $ ls -RF
    .:
    foo  bar*  baz

POSIX.1 2008[1] says about this directory heading:

> If more than one directory, or a combination of non-directory files
> and directories are written, either as a result of specifying
> multiple operands, or the -R option, each list of files within a
> directory shall be preceded by:
>
>     "\n%s:\n", <directory name>
>
> If this string is the first thing to be written, the first <newline>
> shall not be written. This output shall precede the number of units
> in the directory.

In the case described above, ls writes a listing for one directory (.)
and does not list any non-directory files. Therefore, according to the
above specification, the ".:" heading may not be printed, but GNU ls
does do so. I suspect this is an oversight on the side of the
developers of the GNU coreutils.

I am using the following version of GNU ls:

    $ ls --version

    ls (GNU coreutils) 8.20
    Copyright (C) 2012 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    Written by Richard M. Stallman and David MacKenzie.

Thank you very much for your help.
Yours sincerely,
Robert Clausecker

[1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

Message #12 received at 17878-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: fuz <at> fuz.su, 17878-done <at> debbugs.gnu.org
Subject: Re: bug#17878: Possible bug in GNU ls with -R
Date: Mon, 30 Jun 2014 07:23:32 -0600

[Message part 1 (text/plain, inline)]

tag 17878 notabug
thanks

On 06/29/2014 12:06 PM, fuz <at> fuz.su wrote:

>     $ ls -RF
>     .:
>     foo  bar*  baz
> 

>> If more than one directory, or a combination of non-directory files
>> and directories are written, either as a result of specifying
>> multiple operands, or the -R option, each list of files within a
>> directory shall be preceded by:

> In the case described above, ls writes a listing for one directory (.)
> and does not list any non-directory files. Therefore, according to the
> above specification, the ".:" heading may not be printed, but GNU ls
> does do so. I suspect this is an oversight on the side of the
> developers of the GNU coreutils.

This is a mis-interpretation of POSIX.  You missed the "or the -R
option" phrase, which implies this behavior is turned on unconditionally
when a directory is listed recursively even if that directory does not
contain a mix of non-directory files and directories.  That is, the
behavior of listing a directory at the front is triggered either by
specifying multiple command line arguments (either 2 or more
directories, or 1 directory and at least one other argument); or by
using -R.  Another way of looking at it is that you are listing a
combination of directories and regular files - the directory '.'
(implicitly supplied by not giving any arguments) and the regular files
of its contents.

All other ls implementations behave the same.  This is not a bug in
coreutils.  I'm closing the report, although you can feel free to add
more comments.  If you think the wording in POSIX is awkward, then file
a bug there to get it cleaned up (http://austingroupbugs.net/)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 17878 <at> debbugs.gnu.org, eblake <at> redhat.com, fuz <at> fuz.su
Subject: Re: bug#17878: Possible bug in GNU ls with -R
Date: Mon, 30 Jun 2014 09:22:32 -0700

Eric Blake wrote:
> All other ls implementations behave the same.

Unfortunately that's not the case, as AIX 7.1 behaves the way the 
original requestor asked for, as does 7th Edition Unix.  Furthermore, 
the POSIX spec's EXAMPLES section 
<http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_17> 
(admittedly informative) agrees with AIX 7.1 and 7th Edition Unix.  My 
guess is that POSIX intended to specify the traditional behavior. 
However, so many implementations have gotten it wrong that one could 
easily argue the wording is unclear, and that the POSIX wording should 
be fixed to make it clear that both the traditional and the common 
behavior are allowed.  Another possibility is that we could change GNU 
ls to behave like traditional ls.

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

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, 17878 <at> debbugs.gnu.org, fuz <at> fuz.su
Subject: Re: bug#17878: Possible bug in GNU ls with -R
Date: Mon, 30 Jun 2014 11:51:31 -0600

[Message part 1 (text/plain, inline)]

On 06/30/2014 10:22 AM, Paul Eggert wrote:
> Eric Blake wrote:
>> All other ls implementations behave the same.
> 
> Unfortunately that's not the case, as AIX 7.1 behaves the way the
> original requestor asked for, as does 7th Edition Unix.  Furthermore,
> the POSIX spec's EXAMPLES section
> <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_17>
> (admittedly informative) agrees with AIX 7.1 and 7th Edition Unix.  My
> guess is that POSIX intended to specify the traditional behavior.
> However, so many implementations have gotten it wrong that one could
> easily argue the wording is unclear, and that the POSIX wording should
> be fixed to make it clear that both the traditional and the common
> behavior are allowed.  Another possibility is that we could change GNU
> ls to behave like traditional ls.

Then I'll go ahead and raise a defect report with the Austin Group, and
report back here once I get more of a feel for what will happen in POSIX.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: fuz <at> fuz.su
To: 17878 <at> debbugs.gnu.org
Subject: Re: bug#17878: Possible bug in GNU ls with -R
Date: Mon, 30 Jun 2014 20:29:14 +0200

Please keep me updated on this issue and perhaps link the Austin Group
defect in this bug report.

On Mon, Jun 30, 2014 at 11:51:31AM -0600, Eric Blake wrote:
> On 06/30/2014 10:22 AM, Paul Eggert wrote:
> > Eric Blake wrote:
> >> All other ls implementations behave the same.
> > 
> > Unfortunately that's not the case, as AIX 7.1 behaves the way the
> > original requestor asked for, as does 7th Edition Unix.  Furthermore,
> > the POSIX spec's EXAMPLES section
> > <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_17>
> > (admittedly informative) agrees with AIX 7.1 and 7th Edition Unix.  My
> > guess is that POSIX intended to specify the traditional behavior.
> > However, so many implementations have gotten it wrong that one could
> > easily argue the wording is unclear, and that the POSIX wording should
> > be fixed to make it clear that both the traditional and the common
> > behavior are allowed.  Another possibility is that we could change GNU
> > ls to behave like traditional ls.
> 
> Then I'll go ahead and raise a defect report with the Austin Group, and
> report back here once I get more of a feel for what will happen in POSIX.
> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 



-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

Previous Next

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