[Toybox] More expand cleanups

[Jonathan Clairembault]

On Wed, Nov 28, 2012 at 8:51 AM, Rob Landley <rob at landley.net> wrote:
>
> I don't like adding new types to global headers which are only used in one
> command, so change global tablist to be a void *...

That will be used in unexpand but void * is fine anyway.

> Also, in the help text I'm tempted to just say "a comma separated list"
> instead of having comma or space awkwardly explained in the paranethetical.
> Yes we should support space, but since "expand -n 1 2 3" treats 2 and 3 as
> filenames, you need quotes around it to use spaces as a separator which is
> just awkward. If they're going to read the docs to see how to use it, comma
> is fine. If an existing script already provides spaces, we work anyway...
> Wordsmithing a bit.

Make sense.

> Now let's look at expand_file(). Collate all same declaration types, so just
> one line of ssize_t declarations instead of several... and why are we using
> ssize_t for something that it's a file position offset?

Right, that's a mistake.

> Ah, you're using toybuf already, for file input. Reasonable choice. Ok, I'll
> break the parsing logic out into a function that returns the number of
> entries and takes the array to write into as its argument, and have it not
> write anything to the array if the argument is NULL. Then I can call it
> twice, once to count the number of entries and the second time to fill out
> the array.
>
> Back to expand_file(). The downside of using readall() is that interactive
> granularity goes way down. I had this problem with "tee" once upon a time,
> it meant that piping the output of anything through tee made it appear in 4k
> chunks, which meant if you logged the result of a build you couldn't really
> see what the build was doing. I'm not sure expand has the same use cases,
> but that's why I did xread().

Well it seems like gnu/damnit version does buffering as well at least
it does not process input as a line by line basis. I don't see why
using xread changes anything, you probably need fgets here. Though I
think we can safely buffer until someone comes in and raises
interactivity need. wdyt?

> Ah, hang on. Internationalization. This thing is going to need multibyte
> support for utf8, isn't it? (The same general logic as wc -m. Hmmm, I wonder
> if they can share code?)

Ah! I thought toybox was not dealing with internationalization. Though
that's a good thing to have internationalization.

>
> Ok, I'll have to come back to this in the morning.
>
> Rob

Jonathan