bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15828: behavior of ls -f


From: Pádraig Brady
Subject: bug#15828: behavior of ls -f
Date: Fri, 08 Nov 2013 00:06:31 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]