In this example I refer to the expansion of a sequence of integers, but perhaps(?) the limits would be relevant to all aspects of brace expansion.. This more general view is also of interest to me.
seq seems to handle much longer integer sequences than does {1..n} brace expansion (at least, that's the case in this example).
eg 'seq -f @%12.0f 1 1000000000 >/dev/null' .. This expands 1 billion quite happily in 14m 04s
However, echo {1..10000000000} >/dev/null crashes into oblivion from the CLI in 'gnome-terminal' and 'konsole' (...goodbye terminal session!)
The best I could get out of brace expansion for an integer sequence, is approximately {1..15000000}.. only 15 million.
Is this a limitation of the brace expansion itself, or of how echo handles the expanded data?
It seems to be caused by using up all available RAM, but I thought it would use the swap area at that point...
Also (btw), this 15000000 integer sequence, echo {..} takes 57.0s; whereas seq takes only 12.7s ...

bash: xmalloc: ../../../bash/lib/sh/stringvec.c:40: cannot allocate 11280523272 bytes (0 bytes allocated). (bash 3.2.39, amd64.) 15000000 caused too much swapping, so I killed it. You're just asking too much from poor bash. – Gilles Feb 28 '11 at 22:19