/bin/ls sorting bug?

[John Baldwin]

On Monday 21 June 2004 08:48 pm, Greg Black wrote:
> 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.

diff -b

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org