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
sshd pam getpwnam()
Hello! Does anybody know, why sshd call getpwnam() even if user is authenticating via PAM? This broke remote authentication (RADIUS, TACACS+) when user doesn't exist in local password database. -- Alexey Zagarin emax telecommunications ___ [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 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: SPDIF capture device?
Hello, On Fri, Jun 18, 2004 at 01:56:25PM +0200, Ing.Richard Andrysek wrote: I've read your question about SPDIF capture device on freebsd. I am currently looking for similar device.Have you found such one? Can you access subcode etc.? The Soyo Dragon Plus! K7V has a SPDIF input/output; this uses the snd_cmi driver. However, I think some machine specific incantations are necessary to use SPDIF mode, and I don't know what these are. I have such a board but it's not in Desktop use (it's in my CVS server). Some reverse engineering is probably needed here, but if the Linux drivers support this and a change can be crossported easily, I'll happily commit it if people have the means to test it. Regards, BMS pgpklEdbveJRY.pgp Description: PGP signature
Re: -lthr vs. -pthread
At 4:14 AM +0200 6/20/04, Cyrille Lefevre wrote: is it normal that the selected process is the last forked thread and not the thread owner (father) ? I committed the changes, so people can try this if they want. Example: (48) ps -HO lwp,nlwp PIDLWP NLWP TT STAT TIME COMMAND 1870 18701 ?? SL 0:00.13 sshd: [EMAIL PROTECTED] (sshd) 1871 18711 p3 SLs0:00.09 -bash (bash) 2535 126 p3 SL+0:00.00 ./cyr-thread 2535 116 p3 SL+0:00.00 ./cyr-thread 2535 146 p3 SL+0:00.00 ./cyr-thread 2535 25356 p3 SL+0:00.00 ./cyr-thread 2535 106 p3 SL+0:00.00 ./cyr-thread 2535 136 p3 SL+0:00.00 ./cyr-thread (49) ps -O lwp,nlwp PIDLWP NLWP TT STAT TIME COMMAND 1870 18701 ?? S 0:00.13 sshd: [EMAIL PROTECTED] (sshd) 1871 18711 p3 Ss 0:00.09 -bash (bash) 2535 146 p3 S+ 0:00.00 ./cyr-thread When the -H is not requested, why does process 2535 show up as thread-ID #14 instead of #2535? Is that something that we need to change when copying info into kproc_info ? Or is that perfectly reasonable? I have not worked with threaded apps, so I am not sure what people would be expecting here. -- 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: -lthr vs. -pthread
this is a question for marcel, but basically this may change. In current code the thread_id of the first thread is set to be equal to the PID. Marcel and I have discussed reworking the thread_id code and in the new code this will possibly not be true. Under KSE teh original thread has probably exited.. and the one availabel to run is number 14. Under KSE threads are ephemeral, and come-and go as needed. (so the ID actually doesn't mean anything of rgeat significance) On Sun, 20 Jun 2004, Garance A Drosihn wrote: At 4:14 AM +0200 6/20/04, Cyrille Lefevre wrote: is it normal that the selected process is the last forked thread and not the thread owner (father) ? I committed the changes, so people can try this if they want. Example: (48) ps -HO lwp,nlwp PIDLWP NLWP TT STAT TIME COMMAND 1870 18701 ?? SL 0:00.13 sshd: [EMAIL PROTECTED] (sshd) 1871 18711 p3 SLs0:00.09 -bash (bash) 2535 126 p3 SL+0:00.00 ./cyr-thread 2535 116 p3 SL+0:00.00 ./cyr-thread 2535 146 p3 SL+0:00.00 ./cyr-thread 2535 25356 p3 SL+0:00.00 ./cyr-thread 2535 106 p3 SL+0:00.00 ./cyr-thread 2535 136 p3 SL+0:00.00 ./cyr-thread (49) ps -O lwp,nlwp PIDLWP NLWP TT STAT TIME COMMAND 1870 18701 ?? S 0:00.13 sshd: [EMAIL PROTECTED] (sshd) 1871 18711 p3 Ss 0:00.09 -bash (bash) 2535 146 p3 S+ 0:00.00 ./cyr-thread When the -H is not requested, why does process 2535 show up as thread-ID #14 instead of #2535? Is that something that we need to change when copying info into kproc_info ? Or is that perfectly reasonable? I have not worked with threaded apps, so I am not sure what people would be expecting here. -- 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] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -lthr vs. -pthread
On Sun, Jun 20, 2004 at 05:07:56PM -0700, Julian Elischer wrote: this is a question for marcel, but basically this may change. In current code the thread_id of the first thread is set to be equal to the PID. Marcel and I have discussed reworking the thread_id code and in the new code this will possibly not be true. Yes. We need to be sure however that we don't break core file creation. Historically the PRSTATUS note in the core file has the process ID. The current thread LWP allocation allows us to put the Thread ID in the note and have as many notes as there are threads. Non-threaded processes will create core files that are compatible with older tools. If we change the LWP allocation, we will break this and should probably use LWPSTATUS notes for the thread states and use the PRSTATUS note for the process state. In any case, this requires modifications to binutils, so needs to be coordinated. -- Marcel Moolenaar USPA: A-39004 [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 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]
