Limitations on a command line

David Collier from_busybox_maillist at dexdyne.com
Sat Jan 29 01:08:00 UTC 2011


In article <F4AC465B29B61A4FA792A4E6FEA8A2020160C2F9 at wamxm01.ciena.com>,
jcathey at ciena.com (Cathey, Jim) wrote:

> *From:* "Cathey, Jim" <jcathey at ciena.com>
> *To:* <from_busybox_maillist at dexdyne.com>, <busybox at busybox.net>
> *CC:* <jeredb at dexdyne.com>
> *Date:* Fri, 28 Jan 2011 10:41:48 -0800
> 
> >I have some rubbish code I've inherited and don't have time to 
> rewrite,
> >which can spit out
> >
> >   tar file1 file2 file3.... 
> >   
> >where each of the file names is up to 100 chars, and there could 
> be up
> to
> >2000 of them in theory.
> 
> This is what xargs is for.  (Hint: use tar -r)
> 
> 	find glop | xargs -r tar -r archive
> 
> or maybe:
> 
> 	<big-assed-file xargs -r tar -r archive
> 
> Xargs' main job is to ensure that command lines don't end up 'too 
> big',
> assuming that the command can still work if split up some.
> 
> -- Jim

Thanks Jim,

I've worked out that while the code uses full paths to move the files
about, it uses relative paths in the zip command.

so that's 2000 * 50 in the absolute worst case.

It would be nice to know what length of command might break busybox, but
failing that I'll stick an xargs in the command line and pray loudly :-)

D


More information about the busybox mailing list