Date: Mon, 21 Jun 2004 21:01:53 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Greg Black <gjb@gbch.net>, freebsd-hackers@freebsd.org Subject: Re: /bin/ls sorting bug? Message-ID: <p06020421bcfd32db439d@[128.113.24.47]> In-Reply-To: <nospam-1087865330.51081@felix.gbch.net> References: <20040621054406.GA927@VARK.homeunix.com> <200406210910.aa18808@salmon.maths.tcd.ie> <20040621091649.GA92422@iconoplex.co.uk> <20040621133003.GA96338@ussenterprise.ufp.org> <nospam-1087865330.51081@felix.gbch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:48 AM +1000 6/22/04, Greg Black wrote:
>
>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:
Hmm. I never thought much about that before.
Perhaps we should use the output from the `stat' command for
all of these tests in the periodic scripts. That way we could
pick an exact format.
Or maybe those scripts should take advantage of:
LS_COLWIDTHS:
If this variable is set, it is considered to be a colon-
delimited list of minimum column widths. Unreasonable
and insufficient widths are ignored (thus zero signifies
a dynamically sized column). Not all columns have
changeable widths. The fields are, in order: inode,
block count, number of links, user name, group name,
flags, file size, file name.
Those might make the periodic checks more useful. Which scripts
have this problem? In a very quick check, I only noticed an `ls'
command in security/100.chksetuid. Anything else?
Note that I am not volunteering to do the work, though...
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020421bcfd32db439d>