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

Previous Next

Full log

View this message in rfc822 format

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: 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.

Previous Next

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