RE: Limitations on a command line
>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 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: Limitations on a command line
In article , jcat...@ciena.com (Cathey, Jim) wrote: > *From:* "Cathey, Jim" > *To:* , > *CC:* > *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: > > > 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 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Limitations on a command line
Hallo David! > I think I can tame this by suitable use of relative paths, but I'd still > be interested to know There is such a limit. Normal Unix shell has limits of 4 to16k ... and I think busybox ash has limited this even further (got something like 1k in my brain ... but don't know if this includes globbing). You really need that xargs to do your job. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: Limitations on a command line
In article , jcat...@ciena.com (Cathey, Jim) wrote: > *From:* "Cathey, Jim" > *To:* , > *CC:* > *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: > > > 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 Oh TVM - so I can assume xargs chops things into chunks that suit the system it's running on without me needing to be aware of the limits goodee. David ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: Limitations on a command line
>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: http://lists.busybox.net/mailman/listinfo/busybox
Limitations on a command line
Is there any explicit limit on the size of command like busybox can swing round it's head? 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. I can change the limits to keep it all under 64 k or whatever... but is there a magic number even smaller than that I should beware of? A MOMENT LATER I think I can tame this by suitable use of relative paths, but I'd still be interested to know D ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox