On Sunday, Oct 14th 2007 at 22:05 -0000, quoth Tony Nelson: =>At 11:29 AM +1000 10/15/07, Cameron Simpson wrote: =>>On 14Oct2007 17:09, John Summerfield <debian@xxxxxxxxxxxxxxxxxxxxxx> wrote: =>>> Cameron Simpson wrote: =>>>> On 14Oct2007 14:39, I wrote: =>> =>>> It doesn't matter how one creates the commandline, there is a limit on its =>>> size. Here, I'm not concerned about side effects of bad characters such as =>>> & and ;. =>> =>>Sure, but in the code we're discussing: =>> =>> for m in subdir/*report* =>> =>>that limit is not hit. Why not? Because the limit only applies to exec() =>>calls. It is an OS interface limit. For loops take place entirely in =>>user space. There is no "command line" being constructed in the sense =>>you're thinking. => ... => =>Whaddayaknow. => => $ ls /*/*/*/*/* | wc => bash: /bin/ls: Argument list too long => 0 0 0 => $ for n in /*/*/*/*/* ; do echo $n ; done | wc => 211860 218203 7290275 => $ =>-- Ok. I now believe it but I don't understand why. The ls command gets globbed and grows to be too big. But the for commandline has to also grow to the same size. Is it because the forloop is special? Try this $ for n in /*/*/*/*/* ; do echo $n ; done | wc Vs. $ bash -c "for n in /*/*/*/*/* ; do echo \$n ; done | wc" Now the stars get expanded by the outer bash and when the inner bash starts, he doesn't know that there ever were any stars. The funny part is that in the new case the output numbers are different. Note that we are exec'ing a new bash and that that bash only starts after the terminal session has expanded the stars. AFAICT, we seem to be exec'ing an 8M commandline which is bigger than the 130K in limits.h So what's the deal? Am I missing something? -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net
