Limitations on a command line

[David Collier]

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

> *From:* "Cathey, Jim" <jcathey at ciena.com>
> *To:* <busybox at busybox.net>
> *CC:* jeredb at dexdyne.com
> *Date:* Fri, 28 Jan 2011 17:31:38 -0800
> 
> >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
> :-)
> 
> There's _two_ places that can croak: busybox, and
> the kernel's argument buffer.  Xargs is supposed to
> keep it to a manageable level so far as the kernel is
> concerned, it's up to busybox (and any other shell)
> to handle that system-defined size.
> 
> For any kind of a system script that can't know what it
> can reasonably expect to see (i.e. worst case scenarios)
> you should never use shell globbing, but rather find
> and xargs.  They will never fail.
> 
> e.g. What does "rm -f /tmp/*" do if there are 12,000,000
> files in the /tmp directory?  (Hint: nothing good!)
> Whereas "find /tmp -mindepth 1 -maxdepth 1 ! -type d -print0 \
>               | xargs -r0 rm -f" will succeed.  More
> complicated, to be sure, but more robust.

Jim - I'm quite interested in this issue - a customer has just forced us
to up the spec on our data logger so it may have to delete 1000+ files at
once from a log area. I guess that will have the possibility to run into
this issue.

I've just done a pile of googling and now vaguely understand that line!
is the -r0 a typo?


David







> 
> -- Jim
> 
> 
> 
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>