cvs commit: src/bin/ls cmp.c extern.h ls.1 ls.c util.c
bde at zeta.org.au
Sat Jun 4 03:26:31 PDT 2005
On Sat, 4 Jun 2005, Tim Robbins wrote:
> On Fri, Jun 03, 2005 at 11:05:59AM +0000, Dima Dorfman wrote:
>> dd 2005-06-03 11:05:58 UTC
>> FreeBSD src repository
>> Modified files:
>> bin/ls cmp.c extern.h ls.1 ls.c util.c
>> Add the -S option to sort files by size. NetBSD and OpenBSD already
>> have this option with identical semantics (sorting large files first).
>> -r can be used to reverse the sort if that is desired.
> How is this different from |sort -k5,5nr?
It doesn't violate filtering phillosophy and doesn't fail for ls -lh|
(or ls| or ls -C).
-h (human-unreadable) output is fairly machine-unreadable too. Machines
can easily parse it, but sort -n doesn't. The formats accepted by
sort -n are undocumented in sort.1. According to sort.c, they seem
to be only human readable ones (floating point "f" formats plus ones
with thousands separators but no exponentials) and the precision of
the precision of the numbers is unlimited). According to POSIX, they
are supposed be these with with an optional radix character but no
exponentials. POSIX doesn't seem to document what a radix character
is except for printf() etc., and doesn't seem to documented the required
precision. Gnu sort also has a -g option which causes sorting of
numbers in formats understood by strtod(2), so sort -g understands
normal human-unreable exponential formats but not the ones produced
More information about the cvs-all