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.
_
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
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, bi
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
> >
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
On Mon, Jun 21, 2004 at 10:39:53PM -0700, David O'Brien wrote:
> Let me introduce you to that key on your keyboard between the 'S' and 'F'
> keys. Its the 'D' key. Amoung its other good uses (like being used
> twice in "David") is that most MUA's use it to delete emails and threads
> you don't c
On Mon, Jun 21, 2004 at 10:16:49AM +0100, Paul Robinson wrote:
> 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. :-)
Uh, Pau
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 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
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 n
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 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 the
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 nanosec
> 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---
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 ni
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 sort
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 t
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 *
> 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.freebs
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
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 o
On Sat, Jun 19, 2004, Dimitry Andric wrote:
> So, if these fields for two different files are exactly the same, the
> resulting sorted list will have an undefined order for all other
> fields. And AFAICS, there's no way to tell ls: "first sort on time,
> then on filename, then on size", etc. This
> 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? :)
__
On 2004-06-19 at 21:35:45 Scott Mitchell wrote:
> 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 sco
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 th
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
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 sc
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 won
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. U
29 matches
Mail list logo
