Re: /bin/ls sorting bug?
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 ... man 1 diff: -b Ignore changes in amount of white space. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Valentin Nechayev [EMAIL PROTECTED] wrote: Sun, Jun 20, 2004 at 02:34:04, andrit wrote about Re: /bin/ls sorting bug?: But there is nice sort command and power of unix. Don't you remember the initial UNIX concept to make miracles by small things fired together? :) Well, let's disable sorting in ls output totally and give this role to sort. I thinks folks won't adopt this idea, especially said that ls output isn't easily machine-parseable. That's why I've always wanted an ls flag to output the time stamp in time_t form (i.e. seconds since the epoch). Would make a lot of scripts a lot easier. (Yes, I know we've got /usr/bin/stat -r, but that's not portable.) Regards Oliver PS: Don't get me wrong; I'm _not_ asking for such a flag to ls, as it wouldn't help for portable scripts. PPS: FWIW, I like the patch (the second one which takes nanoseconds correctly into account). I would also suggest an option to display the nanoseconds in ls -l output. Maybe when -T is specified twice ...? (That way we wouldn't waste yet another letter.) -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. FreeBSD is Yoda, Linux is Luke Skywalker -- Daniel C. Sobral ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Greg Black [EMAIL PROTECTED] 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: [...] 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. I always use diff -Bb for things like that, i.e. to ignore any changes in whitespace. Works perfectly fine. Maybe someone should just add -b to the diff command in those periodic scripts? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'. -- Oddbjorn Steffensen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Well, -standards says that POSIX is silent on the subject of ls and nanoseconds, so I guess we can do whatever we like... I was going to just commit my original patch and be done with it, but David appears to have beaten me to it: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ls/cmp.c Anyway, bikeshed over :-) Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
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 [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Sun, Jun 20, 2004 at 02:34:04, andrit wrote about Re: /bin/ls sorting bug?: And AFAICS, there's no way to tell ls: first sort on time, then on filename, then on size, etc. This would make a nice addition though. :) But there is nice sort command and power of unix. Don't you remember the initial UNIX concept to make miracles by small things fired together? :) Well, let's disable sorting in ls output totally and give this role to sort. I thinks folks won't adopt this idea, especially said that ls output isn't easily machine-parseable. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Sorting on nanoseconds too is likely to be more confusing than useful. Even if we use one of the precious few option letters ls doesn't use already to add a nanosecond display, most people won't know about it because they don't care about nanoseconds. They might care when they notice---as you did---that the sort order isn't what they expected. At the moment in FreeBSD the nanoseconds field is always zero, unless you twiddle vfs.timestamp_precision, so it would make no difference to joe user. For people that do set vfs.timestamp_precision, it would be nice if ls did the right thing (for example, test already compares the nanoseconds field, after someone submitted a PR because it didn't). Is the point of sorting on nanoseconds to totally order the files based on modification time? Depending on the clock resolution (which is partially determined by vfs.timestamp_precision and partially determined by the actual clock resolution), it may not be enough to totally order the files. David. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Guys, Hate to be the party-pooper, but this thread is starting to smell a bit odd. The smell reminds me of something... when I was a kid at school... during the break ahh, that's it. This thing smells like a bikeshed. :-) For what it's worth the original patch looked good to me. The nanosecond patch is fine too. Please, no more intimate discussion of a command line flag that few people use, and if it doesn't work correctly now could have been worked around with a pipe to sort. I'm guessing the messed up order was because the files that were out of kilter were the files being hard-linked to but don't have the time to check. So in some ways, the output was predictable. Either way, I say commit or let it die... no... more... ls... :-) -- Paul Robinson http://www.iconoplex.co.uk/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On Mon, Jun 21, 2004 at 09:10:47AM +0100, David Malone wrote: Sorting on nanoseconds too is likely to be more confusing than useful. Even if we use one of the precious few option letters ls doesn't use already to add a nanosecond display, most people won't know about it because they don't care about nanoseconds. They might care when they notice---as you did---that the sort order isn't what they expected. At the moment in FreeBSD the nanoseconds field is always zero, unless you twiddle vfs.timestamp_precision, so it would make no difference to joe user. For people that do set vfs.timestamp_precision, it would be nice if ls did the right thing (for example, test already compares the nanoseconds field, after someone submitted a PR because it didn't). I've asked the -standards people whether POSIX says anything about ls and nanoseconds. My research didn't turn up anything, but I'll let them have the final word. Given that our ls has ignored nanos for at least the last 10 years, and that it would make difference to 99% of users if it did, I don't think this is a major issue. I'm tempted to just commit the existing patch as it is, to fix the original bug, then talk about sorting on nanos, and maybe adding a new option to display them. Is the point of sorting on nanoseconds to totally order the files based on modification time? Depending on the clock resolution (which is partially determined by vfs.timestamp_precision and partially determined by the actual clock resolution), it may not be enough to totally order the files. But it (ls) would use the full resolution of the recorded timestamps to produce the displayed ordering, which is probably all you can reasonably ask of it... Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
In a message written on Mon, Jun 21, 2004 at 10:16:49AM +0100, Paul Robinson wrote: For what it's worth the original patch looked good to me. The nanosecond patch is fine too. Please, no more intimate discussion of a command line I'd like to put forth a different argument why the nanosecond patch is a better patch. 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. Since today, for almost all users nanos is 0 there's no impact on most of the users. For the few users where nanos isn't 0, the impact is that if we do the non-nanos patch now, and then at some point in the future add the nanos patch, at that transition old and new ls will produce different output for the nanos users. So, if we're going to alter the output and make people look at their diffs (or whatever) once with puzzlement, we should make sure it's only once. Put another way, the man page says: -t Sort by time modified (most recently modified first) before sort- ing the operands by lexicographical order. Since it doesn't have a resolution, if I was a nanos user and it didn't sort by nanos, I'd be a bit annoyed. Having -t work correctly is the right option. The fact that there is no way to display nanos is a separate bug. Don't let the existance of one bug prevent you from fixing another one. Note, I advocate -T display nanos. Humm, I didn't want to debate command line options (as the parent suggested) but I put two in my post. Can't win 'em all. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpkVmPPYkvt3.pgp Description: PGP signature
Re: /bin/ls sorting bug?
On Mon, Jun 21, 2004, David Malone wrote: Sorting on nanoseconds too is likely to be more confusing than useful. Even if we use one of the precious few option letters ls doesn't use already to add a nanosecond display, most people won't know about it because they don't care about nanoseconds. They might care when they notice---as you did---that the sort order isn't what they expected. At the moment in FreeBSD the nanoseconds field is always zero, unless you twiddle vfs.timestamp_precision, so it would make no difference to joe user. For people that do set vfs.timestamp_precision, it would be nice if ls did the right thing (for example, test already compares the nanoseconds field, after someone submitted a PR because it didn't). Is the point of sorting on nanoseconds to totally order the files based on modification time? Depending on the clock resolution (which is partially determined by vfs.timestamp_precision and partially determined by the actual clock resolution), it may not be enough to totally order the files. Yep, that was going to be my next point. I don't think this is particularly useful, or necessarily even a good idea, but AFAIK POSIX doesn't say anything about using a consistent timer resolution when processing file timestamps, so don't let that stop you... Now let's re-raise the *original* bikeshed of adding nanosecond support to sleep! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
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 pgp48IsoIRwGf.pgp Description: PGP signature
Re: /bin/ls sorting bug?
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= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On Sat, Jun 19, 2004 at 11:52:29PM +0100, Scott Mitchell wrote:
On Sat, Jun 19, 2004 at 10:06:01PM +0200, Dimitry Andric wrote:
Looking through ls source shows that the sorting is done by passing a
comparison function to fts_open(3). In the case of sorting by
modification time, the *only* comparison made is of the mtime fields:
You did see the patch attached to my original post, right? It modifies all
of these comparison functions to sort the two items by name (or reverse
name) in the case that their timestamps are equal.
Hi Scott,
Could you produce a version of your patch that uses the nanoseconds
field too? I produced the one below, but I think the style in your
patch was nicer. Also, I wonder if the revblahcmp functions should
just call blahcmp with their arguments reversed?
David.
Index: cmp.c
===
RCS file: /cvs/FreeBSD-CVS/src/bin/ls/cmp.c,v
retrieving revision 1.13
diff -u -r1.13 cmp.c
--- cmp.c 6 Apr 2004 20:06:47 - 1.13
+++ cmp.c 19 Jun 2004 21:23:01 -
@@ -63,35 +63,107 @@
int
modcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_mtime - a-fts_statp-st_mtime);
+ if (b-fts_statp-st_mtimespec.tv_sec
+ a-fts_statp-st_mtimespec.tv_sec)
+ return 1;
+ if (b-fts_statp-st_mtimespec.tv_sec
+ a-fts_statp-st_mtimespec.tv_sec)
+ return -1;
+ if (b-fts_statp-st_mtimespec.tv_nsec
+ a-fts_statp-st_mtimespec.tv_nsec)
+ return 1;
+ if (b-fts_statp-st_mtimespec.tv_nsec
+ a-fts_statp-st_mtimespec.tv_nsec)
+ return -1;
+ return (strcoll(a-fts_name, b-fts_name));
}
int
revmodcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_mtime - b-fts_statp-st_mtime);
+ if (a-fts_statp-st_mtimespec.tv_sec
+ b-fts_statp-st_mtimespec.tv_sec)
+ return 1;
+ if (a-fts_statp-st_mtimespec.tv_sec
+ b-fts_statp-st_mtimespec.tv_sec)
+ return -1;
+ if (a-fts_statp-st_mtimespec.tv_nsec
+ b-fts_statp-st_mtimespec.tv_nsec)
+ return 1;
+ if (a-fts_statp-st_mtimespec.tv_nsec
+ b-fts_statp-st_mtimespec.tv_nsec)
+ return -1;
+ return (strcoll(b-fts_name, a-fts_name));
}
int
acccmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_atime - a-fts_statp-st_atime);
+ if (b-fts_statp-st_atimespec.tv_sec
+ a-fts_statp-st_atimespec.tv_sec)
+ return 1;
+ if (b-fts_statp-st_atimespec.tv_sec
+ a-fts_statp-st_atimespec.tv_sec)
+ return -1;
+ if (b-fts_statp-st_atimespec.tv_nsec
+ a-fts_statp-st_atimespec.tv_nsec)
+ return 1;
+ if (b-fts_statp-st_atimespec.tv_nsec
+ a-fts_statp-st_atimespec.tv_nsec)
+ return -1;
+ return (strcoll(a-fts_name, b-fts_name));
}
int
revacccmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_atime - b-fts_statp-st_atime);
+ if (a-fts_statp-st_atimespec.tv_sec
+ b-fts_statp-st_atimespec.tv_sec)
+ return 1;
+ if (a-fts_statp-st_atimespec.tv_sec
+ b-fts_statp-st_atimespec.tv_sec)
+ return -1;
+ if (a-fts_statp-st_atimespec.tv_nsec
+ b-fts_statp-st_atimespec.tv_nsec)
+ return 1;
+ if (a-fts_statp-st_atimespec.tv_nsec
+ b-fts_statp-st_atimespec.tv_nsec)
+ return -1;
+ return (strcoll(b-fts_name, a-fts_name));
}
int
statcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_ctime - a-fts_statp-st_ctime);
+ if (b-fts_statp-st_ctimespec.tv_sec
+ a-fts_statp-st_ctimespec.tv_sec)
+ return 1;
+ if (b-fts_statp-st_ctimespec.tv_sec
+ a-fts_statp-st_ctimespec.tv_sec)
+ return -1;
+ if (b-fts_statp-st_ctimespec.tv_nsec
+ a-fts_statp-st_ctimespec.tv_nsec)
+ return 1;
+ if (b-fts_statp-st_ctimespec.tv_nsec
+ a-fts_statp-st_ctimespec.tv_nsec)
+ return -1;
+ return (strcoll(a-fts_name, b-fts_name));
}
int
revstatcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_ctime - b-fts_statp-st_ctime);
+ if (a-fts_statp-st_ctimespec.tv_sec
+ b-fts_statp-st_ctimespec.tv_sec)
+ return 1;
+ if (a-fts_statp-st_ctimespec.tv_sec
+ b-fts_statp-st_ctimespec.tv_sec)
+ return -1;
+ if (a-fts_statp-st_ctimespec.tv_nsec
+ b-fts_statp-st_ctimespec.tv_nsec)
+ return 1;
+ if (a-fts_statp-st_ctimespec.tv_nsec
+ b-fts_statp-st_ctimespec.tv_nsec)
+ return -1;
+ return (strcoll(b-fts_name, a-fts_name));
}
___
[EMAIL
Re: /bin/ls sorting bug?
On Sun, Jun 20, 2004 at 09:59:12AM +0100, David Malone wrote:
On Sat, Jun 19, 2004 at 11:52:29PM +0100, Scott Mitchell wrote:
On Sat, Jun 19, 2004 at 10:06:01PM +0200, Dimitry Andric wrote:
Looking through ls source shows that the sorting is done by passing a
comparison function to fts_open(3). In the case of sorting by
modification time, the *only* comparison made is of the mtime fields:
You did see the patch attached to my original post, right? It modifies all
of these comparison functions to sort the two items by name (or reverse
name) in the case that their timestamps are equal.
Hi Scott,
Could you produce a version of your patch that uses the nanoseconds
field too? I produced the one below, but I think the style in your
patch was nicer. Also, I wonder if the revblahcmp functions should
just call blahcmp with their arguments reversed?
David.
David,
New patch attached that compares against the nanos field as well. It could
stand a bit of cleaning up to remove the overly long lines.
I'm not sure I'd want this in the tree unless we also had an option to
display the nanoseconds - as it stands you could get items apparently
ordered wrongly, unless you knew the value of their nanos fields. I could
do that if people thought it would be useful.
Scott
--
===
Scott Mitchell | PGP Key ID | Eagles may soar, but weasels
Cambridge, England | 0x54B171B9 | don't get sucked into jet engines
scott at fishballoon.org | 0xAA775B8B | -- Anon
Index: cmp.c
===
RCS file: /home/ncvs/src/bin/ls/cmp.c,v
retrieving revision 1.13
diff -u -r1.13 cmp.c
--- cmp.c 6 Apr 2004 20:06:47 - 1.13
+++ cmp.c 20 Jun 2004 14:33:14 -
@@ -63,35 +63,47 @@
int
modcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_mtime - a-fts_statp-st_mtime);
+ return (a-fts_statp-st_mtimespec.tv_sec == b-fts_statp-st_mtimespec.tv_sec
?
+ (a-fts_statp-st_mtimespec.tv_nsec ==
b-fts_statp-st_mtimespec.tv_nsec ?
+ namecmp(a, b) :
+ b-fts_statp-st_mtimespec.tv_nsec -
a-fts_statp-st_mtimespec.tv_nsec) :
+ b-fts_statp-st_mtimespec.tv_sec -
a-fts_statp-st_mtimespec.tv_sec);
}
int
revmodcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_mtime - b-fts_statp-st_mtime);
+ return modcmp(b, a);
}
int
acccmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_atime - a-fts_statp-st_atime);
+ return (a-fts_statp-st_atimespec.tv_sec == b-fts_statp-st_atimespec.tv_sec
?
+ (a-fts_statp-st_atimespec.tv_nsec ==
b-fts_statp-st_atimespec.tv_nsec ?
+ namecmp(a, b) :
+ b-fts_statp-st_atimespec.tv_nsec -
a-fts_statp-st_atimespec.tv_nsec) :
+ b-fts_statp-st_atimespec.tv_sec -
a-fts_statp-st_atimespec.tv_sec);
}
int
revacccmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_atime - b-fts_statp-st_atime);
+ return acccmp(b, a);
}
int
statcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_ctime - a-fts_statp-st_ctime);
+ return (a-fts_statp-st_ctimespec.tv_sec == b-fts_statp-st_ctimespec.tv_sec
?
+ (a-fts_statp-st_ctimespec.tv_nsec ==
b-fts_statp-st_ctimespec.tv_nsec ?
+ namecmp(a, b) :
+ b-fts_statp-st_ctimespec.tv_nsec -
a-fts_statp-st_ctimespec.tv_nsec) :
+ b-fts_statp-st_ctimespec.tv_sec -
a-fts_statp-st_ctimespec.tv_sec);
}
int
revstatcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_ctime - b-fts_statp-st_ctime);
+ return statcmp(b, a);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On Sun, Jun 20, 2004, Scott Mitchell wrote: On Sun, Jun 20, 2004 at 09:59:12AM +0100, David Malone wrote: On Sat, Jun 19, 2004 at 11:52:29PM +0100, Scott Mitchell wrote: On Sat, Jun 19, 2004 at 10:06:01PM +0200, Dimitry Andric wrote: Looking through ls source shows that the sorting is done by passing a comparison function to fts_open(3). In the case of sorting by modification time, the *only* comparison made is of the mtime fields: You did see the patch attached to my original post, right? It modifies all of these comparison functions to sort the two items by name (or reverse name) in the case that their timestamps are equal. Hi Scott, Could you produce a version of your patch that uses the nanoseconds field too? I produced the one below, but I think the style in your patch was nicer. Also, I wonder if the revblahcmp functions should just call blahcmp with their arguments reversed? David. David, New patch attached that compares against the nanos field as well. It could stand a bit of cleaning up to remove the overly long lines. I'm not sure I'd want this in the tree unless we also had an option to display the nanoseconds - as it stands you could get items apparently ordered wrongly, unless you knew the value of their nanos fields. I could do that if people thought it would be useful. Sorting on nanoseconds too is likely to be more confusing than useful. Even if we use one of the precious few option letters ls doesn't use already to add a nanosecond display, most people won't know about it because they don't care about nanoseconds. They might care when they notice---as you did---that the sort order isn't what they expected. Is the point of sorting on nanoseconds to totally order the files based on modification time? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
/bin/ls sorting bug?
Hi all,
ls(1) says that the -t option will:
Sort by time modified (most recently modified first) before sort-
ing the operands by lexicographical order.
which I take to mean that items (in the same directory) with the same
timestamp should be further sorted according to their names. Unfortunately
it doesn't really work that way:
(562) tuatara:/tmp/foo $ ls -lt
total 0
-rw-rw-r-- 1 scott wheel 0 19 Jun 17:48 c
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 b
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 d
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 e
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 f
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 g
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 h
-rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 i
-rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 j
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 a
-rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 k
This is on a 4.10-PRERELEASE machine, but the -CURRENT code seems to be
identical as far as sorting goes.
Is this intended behaviour? If so, the documentation is wrong. Otherwise,
the attached patch produces the expected output. I can commit it if there
are no objections.
Scott
--
===
Scott Mitchell | PGP Key ID | Eagles may soar, but weasels
Cambridge, England | 0x54B171B9 | don't get sucked into jet engines
scott at fishballoon.org | 0xAA775B8B | -- Anon
Index: cmp.c
===
RCS file: /home/ncvs/src/bin/ls/cmp.c,v
retrieving revision 1.9.2.2
diff -u -r1.9.2.2 cmp.c
--- cmp.c 8 Jul 2002 06:59:27 - 1.9.2.2
+++ cmp.c 19 Jun 2004 16:54:55 -
@@ -67,35 +67,47 @@
int
modcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_mtime - a-fts_statp-st_mtime);
+ return (a-fts_statp-st_mtime == b-fts_statp-st_mtime ?
+ namecmp(a, b) :
+ b-fts_statp-st_mtime - a-fts_statp-st_mtime);
}
int
revmodcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_mtime - b-fts_statp-st_mtime);
+ return (a-fts_statp-st_mtime == b-fts_statp-st_mtime ?
+ revnamecmp(a, b) :
+ a-fts_statp-st_mtime - b-fts_statp-st_mtime);
}
int
acccmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_atime - a-fts_statp-st_atime);
+ return (a-fts_statp-st_atime == b-fts_statp-st_atime ?
+ namecmp(a, b) :
+ b-fts_statp-st_atime - a-fts_statp-st_atime);
}
int
revacccmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_atime - b-fts_statp-st_atime);
+ return (a-fts_statp-st_atime == b-fts_statp-st_atime ?
+ revnamecmp(a, b) :
+ a-fts_statp-st_atime - b-fts_statp-st_atime);
}
int
statcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_ctime - a-fts_statp-st_ctime);
+ return (a-fts_statp-st_ctime == b-fts_statp-st_ctime ?
+ namecmp(a, b) :
+ b-fts_statp-st_ctime - a-fts_statp-st_ctime);
}
int
revstatcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_ctime - b-fts_statp-st_ctime);
+ return (a-fts_statp-st_ctime == b-fts_statp-st_ctime ?
+ revnamecmp(a, b) :
+ a-fts_statp-st_ctime - b-fts_statp-st_ctime);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Scott Mitchell wrote: ls(1) says that the -t option will: Sort by time modified (most recently modified first) before sort- ing the operands by lexicographical order. ... the attached patch produces the expected output. I can commit it if there are no objections. Looks good to me. I wonder if the time sorting should include the nanos field as well. (Mostly on FreeBSD, the nanos field is zero, but not always.) Of course, sorting on the (non-displayed) nanos field could also produce such unexpected output as you describe. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On 2004-06-19 at 19:50:07 Scott Mitchell wrote: (562) tuatara:/tmp/foo $ ls -lt total 0 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:48 c -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 b -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 d -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 e -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 f -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 g -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 h -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 i -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 j -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 a -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 k Can you please show the output of ls -ltT ? pgpXwTsAylawE.pgp Description: PGP signature
Re: /bin/ls sorting bug?
On Sat, Jun 19, 2004 at 09:01:37PM +0200, Dimitry Andric wrote: On 2004-06-19 at 19:50:07 Scott Mitchell wrote: (562) tuatara:/tmp/foo $ ls -lt total 0 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:48 c -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 b -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 d -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 e -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 f -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 g -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 h -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 i -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 j -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 a -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 k Can you please show the output of ls -ltT ? Sure (added -i to make it easier to see what's going on here): (505) tuatara:/tmp/foo $ ls -iltT total 0 35 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:48:40 2004 c 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 b 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 d 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 e 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 f 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 g 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 h 41 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 i 51 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 j 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 a 52 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 k Most of those files (a,b,d,e,f,g,h) are hard-linked to each other - so they definitely share the same timestamp. i,j,k were created with 'touch -r a i j k', so they should also have the same time. c is different to make sure I didn't break the sort order when files *did* have different times. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On Sat, Jun 19, 2004 at 11:47:21AM -0700, Tim Kientzle wrote: Scott Mitchell wrote: ls(1) says that the -t option will: Sort by time modified (most recently modified first) before sort- ing the operands by lexicographical order. ... the attached patch produces the expected output. I can commit it if there are no objections. Looks good to me. I wonder if the time sorting should include the nanos field as well. (Mostly on FreeBSD, the nanos field is zero, but not always.) I don't see why not, unless some standard requires the nanos to be ignored. That would be pretty strange though... Of course, sorting on the (non-displayed) nanos field could also produce such unexpected output as you describe. I guess you'd want yet another option to display the full-resolution timestamp, if you were going to sort on the whole thing. And you'd still want to use the name to break ties. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
And AFAICS, there's no way to tell ls: first sort on time, then on filename, then on size, etc. This would make a nice addition though. :) But there is nice sort command and power of unix. Don't you remember the initial UNIX concept to make miracles by small things fired together? :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug? - change it.
At 6:50 PM +0100 6/19/04, Scott Mitchell wrote: Is this intended behaviour? If so, the documentation is wrong. Otherwise, the attached patch produces the expected output. I can commit it if there are no objections. Your patch looks like a reasonable change to me. By definition, there can be no one which *depends* on the present behavior in this situation, because the present behavior is not consistent. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Don't you remember the initial UNIX concept to make miracles by small things fired together? :) That's a very nice quote! Gonna answer that the next time someone asks me what UNIX is. :-) GH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
