GNU bug report logs - #15828
behavior of ls -f

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 15828 in the body.
You can then email your comments to 15828 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: Aharon Robbins <arnold <at> skeeve.com>
To: bug-coreutils <at> gnu.org
Subject: behavior of ls -f
Date: Thu, 07 Nov 2013 20:54:32 +0200

Hello.

There is a difference between the Solaris ls and ls on GNU/Linux
and many other systems. In particular, ls -f turns off -l (and other
options, see below).

This breaks a test I have in the gawk test suite.

The citation from POSIX:

> > The readdir test fails because the -f option to ls turns off -l. I think
> > the Solaris ls is broken.
>
> This is perfectly POSIX-compliant behavior. See
>   http://pubs.opengroup.org/onlinepubs/000095399/utilities/ls.html
>
> -f [XSI]  Force each argument to be interpreted as a directory and list the
>    name found in each slot. This option shall turn off -l, -t, -s, and -r, and
>    shall turn on -a; the order is the order in which entries appear in the directory. 

And even if I set POSIXLY_CORRECT GNU/Linux ls doesn't turn off -l.

	$ ls --version
	ls (GNU coreutils) 8.13

I will probably rewrite my test (sigh).

In the meantime, comments?

Thanks,

Arnold

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Aharon Robbins <arnold <at> skeeve.com>
Cc: 15828 <at> debbugs.gnu.org
Subject: Re: bug#15828: behavior of ls -f
Date: Thu, 07 Nov 2013 19:57:28 +0000

tag 15828 notabug
close 15828
stop

On 11/07/2013 06:54 PM, Aharon Robbins wrote:
> Hello.
> 
> There is a difference between the Solaris ls and ls on GNU/Linux
> and many other systems. In particular, ls -f turns off -l (and other
> options, see below).
> 
> This breaks a test I have in the gawk test suite.
> 
> The citation from POSIX:
> 
>>> The readdir test fails because the -f option to ls turns off -l. I think
>>> the Solaris ls is broken.
>>
>> This is perfectly POSIX-compliant behavior. See
>>   http://pubs.opengroup.org/onlinepubs/000095399/utilities/ls.html
>>
>> -f [XSI]  Force each argument to be interpreted as a directory and list the
>>    name found in each slot. This option shall turn off -l, -t, -s, and -r, and
>>    shall turn on -a; the order is the order in which entries appear in the directory. 
> 

The newest POSIX says "may turn off" -l:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html

> And even if I set POSIXLY_CORRECT GNU/Linux ls doesn't turn off -l.
> 
> 	$ ls --version
> 	ls (GNU coreutils) 8.13
> 
> I will probably rewrite my test (sigh).
> 
> In the meantime, comments?

FreeBSD and GNU ls are in sync and don't turn off -l with -f
solaris is compliant but divergent here.

I don't see a need for -f to ignore any -l,
hence I'm closing this issue for now.

thanks,
Pádraig.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>, 
 Aharon Robbins <arnold <at> skeeve.com>
Cc: 15828 <at> debbugs.gnu.org
Subject: Re: bug#15828: behavior of ls -f
Date: Thu, 07 Nov 2013 12:02:02 -0800

On 11/07/2013 11:57 AM, Pádraig Brady wrote:
> I don't see a need for -f to ignore any -l

One could argue that -f should disable -l
if _POSIX2_VERSION is 200112 or earlier,
I'm not sure it's worth the hassle to
implement that, though.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Aharon Robbins <arnold <at> skeeve.com>
Cc: 15828 <at> debbugs.gnu.org
Subject: Re: bug#15828: behavior of ls -f
Date: Thu, 07 Nov 2013 22:34:53 +0100

On 11/07/2013 07:54 PM, Aharon Robbins wrote:
> And even if I set POSIXLY_CORRECT GNU/Linux ls doesn't turn off -l.

Maybe I've misread the whole thread, but GNU coreutils ls(1) turns
off -l when the -f option follows:

  $ src/ls -lf AUTHORS NEWS
  AUTHORS  NEWS

while -l wins after -f:

  $ src/ls -fl AUTHORS NEWS
  -rw-r--r-- 1 berny users   3669 Feb 10  2013 AUTHORS
  -rw-r--r-- 1 berny users 167110 Nov  5 08:52 NEWS

I don't see an issue there.

Have a nice day,
Berny

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Aharon Robbins <arnold <at> skeeve.com>, 15828 <at> debbugs.gnu.org
Subject: Re: bug#15828: behavior of ls -f
Date: Fri, 08 Nov 2013 00:06:31 +0000

On 11/07/2013 09:34 PM, Bernhard Voelker wrote:
> On 11/07/2013 07:54 PM, Aharon Robbins wrote:
>> And even if I set POSIXLY_CORRECT GNU/Linux ls doesn't turn off -l.
> 
> Maybe I've misread the whole thread, but GNU coreutils ls(1) turns
> off -l when the -f option follows:
> 
>   $ src/ls -lf AUTHORS NEWS
>   AUTHORS  NEWS
> 
> while -l wins after -f:
> 
>   $ src/ls -fl AUTHORS NEWS
>   -rw-r--r-- 1 berny users   3669 Feb 10  2013 AUTHORS
>   -rw-r--r-- 1 berny users 167110 Nov  5 08:52 NEWS
> 
> I don't see an issue there.

Apart from inconsistency I suppose.

You're right that option order matters with GNU ls currently.
It does not matter on FreeBSD at least, as there, -f does not
turn off -l no matter which order they occur.

Comparing some other options that POSIX is more concrete about
in combination with -f, consider -S. POSIX says that:
"When -f is specified, any occurrences of the -r, -S, and -t options shall be ignored"
Now GNU ls does put order significance on the -S option which you can
see by running `/bin/ls -flS`, and that does seem to contravene POSIX.

But option order precedence issue is more general really.
Guideline 11 in http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
states that order shouldn't matter, but we've backwards compat to
worry about.  Also having later options override earlier ones
does allow one to for example alias a default set of ls options,
which one can later change as needed.

thanks,
Pádraig.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Aharon Robbins <arnold <at> skeeve.com>, 15828 <at> debbugs.gnu.org
Subject: Re: bug#15828: behavior of ls -f
Date: Fri, 08 Nov 2013 07:21:25 +0100

On 11/08/2013 01:06 AM, Pádraig Brady wrote:
> On 11/07/2013 09:34 PM, Bernhard Voelker wrote:
>> I don't see an issue there.
> 
> Apart from inconsistency I suppose.
> 
> You're right that option order matters with GNU ls currently.
> It does not matter on FreeBSD at least, as there, -f does not
> turn off -l no matter which order they occur.
> 
> Comparing some other options that POSIX is more concrete about
> in combination with -f, consider -S. POSIX says that:
> "When -f is specified, any occurrences of the -r, -S, and -t options shall be ignored"
> Now GNU ls does put order significance on the -S option which you can
> see by running `/bin/ls -flS`, and that does seem to contravene POSIX.
> 
> But option order precedence issue is more general really.
> Guideline 11 in http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
> states that order shouldn't matter, but we've backwards compat to
> worry about.  Also having later options override earlier ones
> does allow one to for example alias a default set of ls options,
> which one can later change as needed.

Thanks for the clarification.
It was a bit hard to understand without a live BSD system or
the actual commands including the output.

Thanks & have a nice day,
Berny

Previous Next

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