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.
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
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
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,
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
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
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
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
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
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
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
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
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
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*
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
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
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.
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
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
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
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
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? :)
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
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
24 matches
Mail list logo
