[Toybox] Implemented split, pondering a release.

[Rob Landley]

On 06/18/2013 08:55:42 AM, Isaac wrote:
> On Mon, Jun 17, 2013 at 02:22:11AM -0500, Rob Landley wrote:
> > I actually got some time to myself this weekend (visited my sister
> > while the kids were at their father's and she was at work for part
> > of it), so I banged out one of the remaining low-hanging-fruit
> > commands that aboriginal linux (actually linux from scratch) needs
> > to build: split. Got it finished, tested, and checked in, and added
> > tests for it to the test suite.
> >
> > Starting to think about a release. I've got to do an aboriginal
> > linux release for the 3.10 kernel in a couple weeks, and I generally
> > flush pending toybox stuff into a release so that can use it. (Three
> > fewer busybox commands, 42 left several of which are duplicates like
> > "[ [[ test" and "ash sh", and of course the toybox multiplexer.)
> >
> > I'd like to finish the ifconfig cleanup, and documenting all that.
> > Beyond that nothing's really a release blocker, but I'm open to
> > suggestions.
> 
> Sounds good to me.
> 
> > (I feel hugely guilty about not getting mount.c looked at. That's
> > probably the first thing up for next release. Well, I have a
> > half-finished umount.c that I might do first because it's smaller
> > and the three mount/umount/losetup are sort of a group. To do mount
> > I need to set up test environments for nfs and samba, and finally
> > get the root support in scripts/test so I can do a mount.test...)
> 
> I doubt that it could happen before a 3.10 release...
> Doing mount/umount for the next release sounds sensible to me.
> 
> Oh, there's a trivial option to add to modinfo: -b <basedir>
> (used for constructing an initrd-it locates the modules within
> a given directory).

Um, where's this from? My host's modinfo hasn't got it, and I don't  
know of an actual standard for this...

> I have a patch to add it, but I'm wondering why
> NEWTOY(..."<b:F:0"...)
> GLOBALS(
>   char *field;
>   char *basedir;
> ..
> works right, and putting the GLOBALS in the same order as the
> option string breaks (tested on glibc and musl).

The option strings parse from right to left. F: is the rightmost  
captured string so it goes in the first slot, b: is in the next  
rightmost captured string, so it goes in the second slot.

The documentation describes this:  
http://landley.net/toybox/code.html#lib_args

> modinfo also should support specifying an absolute or relative path
> to a module; the one complication is that modinfo_file() takes a
> struct dirtree, not a filename; can dirtree_read handle a filename
> or a relative path?

Yes: http://landley.net/toybox/code.html#lib_dirtree

Rob
 1371703448.0