On Wed, Nov 28, 2012 at 8:51 AM, Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
