/bin/ls sorting bug?

[Greg Black]

On 2004-06-21, Leo Bicknell wrote:

> While I think the particular sort order (current behavior vrs non
> nano patch vrs nano patch) is largely unimportant, I think consistency
> is very important.  It's quite common to do things like using diff
> on the output of commands like ls (indeed, I think several of the
> built in periodic scripts to this), and for that having a _reproduceable_
> order is important.

The output of ls has never been good for reproduceable output
for identical data.  It frequently leads to gigantic "diffs" in
periodic reports which makes them useless, as far as I can
tell.  Take the following case:

    $ mkdir foo
    $ touch foo/a
[1] $ ls -l foo
    total 0
    -rw-r--r--  1 gjb  gjb  0 Jun 22 10:25 a
    $ touch foo/b       
[2] $ ls -l foo
    total 0
    -rw-r--r--  1 gjb  gjb  0 Jun 22 10:25 a
    -rw-r--r--  1 gjb  gjb  0 Jun 22 10:26 b
    $ sudo chown nobody foo/a
[3] $ ls -l foo
    total 0
    -rw-r--r--  1 nobody  gjb  0 Jun 22 10:25 a
    -rw-r--r--  1 gjb     gjb  0 Jun 22 10:26 b

If we diff the output of ls[1] and ls[2], we'll get a useful
answer that shows us that "b" was added.

But if we diff ls[2] and ls[3], it will appear as though every
entry has changed, although only "b" has.  When this happens in
big directories, the consequences are astonishingly bad.

What we need is a canonical output form for this kind of use
that can be fed to a custom diff that can operate on individual
fields.

Oh, but wait, we can do it anyway using standard tools.  Maybe
somebody could fix the periodic scripts instead of continuing
the ls bikeshed:

[4] $ ls -l foo | tr -s ' '
    total 0
    -rw-r--r-- 1 gjb gjb 0 Jun 22 10:25 a
    -rw-r--r-- 1 gjb gjb 0 Jun 22 10:26 b
    $ sudo chown nobody foo/a
[5] $ ls -l foo | tr -s ' '
    total 0
    -rw-r--r-- 1 nobody gjb 0 Jun 22 10:25 a
    -rw-r--r-- 1 gjb gjb 0 Jun 22 10:26 b

The output of ls[4] is in our canonical format, i.e., with one
space between fields; when diff'd against the output of ls[5],
only the single changed file will show up.  Great, this is
useful output.

Cheers, Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 249 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040622/43af1eed/attachment.bin