[Toybox] ls implementation

[Rob Landley]

On 02/12/2012 02:22 PM, Andre Renaud wrote:
> Hi Rob,
> 
> On 11/02/12 00:42, Rob Landley wrote:
>> On 02/09/2012 05:18 PM, Andre Renaud wrote:
>>> Hi,
>>> Out of curiosity I had a go at implementing the 'ls' command in toybox,
>>> just to see how involved it would be. I'm not entirely sure how patch
>>> submission is done for toybox, and I'm not too familiar with mercurial,
>>> but attached is the toys/ls.c file if you're interested.
>>>
>>> It is quite limited - it only supports directories as parameters (ie:
>>> you can't do ls *.c), and only supports a couple of the ls options.
>>>
>>> Any comments?
>>
>> It looks good at first glance.  I don't have time for a proper review
>> this morning but hopefully after work I can merge it.
> 
> I've added a couple of bits to it, so that it supports ls -lFa1. The
> main thing missing is support for files in the command line (currently
> it only supports directories).

And -R support.

I have a lib/dirtree.c which recurses, but which needs work.  Right now
cp uses it (and the still somewhat stubby mdev), and it handles the
funky -HLP behavior correctly which comes up in a bunch of other apps.

But the scandir() thing you're using out of libc has a couple advantages:

1) Free-ish sort behavior, although we need various time sorts and so
on, and I have no idea if bionic implements this.

2) It reads entries in batches, which is nice for the
https://lists.sourceforge.net/lists/listinfo/v9fs-developer guys who had
the problem that a round trip network transaction to read each directory
entry is a big performance bottleneck.  (We had a discussion about this
on the list a year or so back, but alas the sourceforge mailing list
archive is so horrible google apparently doesn't index it.)

There's also a downside of my dirtree stuff that it's using toybuf[]
(library stuff shouldn't) and that limits it to 4k (which beats a
malloc/free for each file, but I should be able to realloc() to the
largest size as it goes down the tree or something...)

And having both readdir() _and_ scandir() based stuff in a waste,
sucking in two library functions to do similar things.  Implies I should
migrate dirtree.c to use scandir...

I need to do some design cleanup here, but that's my problem not yours. :)

> I hope non-inline attachments are ok for patches.

That's fine.  In fact it's easier on me.

(Linus Torvalds used to append all the email messages with patches he
liked to one big file and then apply it as a giant patch at the end of
an email session.  This was back before he had source control, and
that's why linux-kernel standardized on that way.)

> Regards,
> Andre

Rob

 1329190922.0