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 ...

  • The question is interesting, but I think the "real" answer — that is, beyond the academic interest — is definitely this is one of those signs that it's time to switch to a scripting language. – mattdm Feb 28 '11 at 16:48
  • 1
    You're asking too much memory from bash. On my machine, 10000000000 immediately crashed bash with 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 'SO- stop being evil' Feb 28 '11 at 22:19

echo {1..5} is expanded into the command echo 1 2 3 4 5 which is then expanded in the usual way. It is not at all similar to seq 1 1000000000 >/dev/null, which never expands to a command with very many arguments.

It is more like echo $(seq 1 1000000000): I guess this breaks in the same way?

The problem you are running into is to do with handling large commands, which Unix has always been fussy about, which is to say it is a general problem with handling command strings. It is one of the things Perl was written to fix.

I'd file a polite and informative bug report anyway: it might provoke an interesting discussion.

  • Thanks for the answer. Your comment, "It is not at all similar to seq..." put things into sharp relief; the penny dropped... I just now Alt-Tabbed to check my Terminal for the progress of echo $(seq 1 1000000000), but the Terminal had vanished :) ... So, I gather that it is nothing to do specifically with either echo or brace-expansion... and that it is simply a matter of running out of RAM ... btw, this issue arose from this question: unix.stackexchange.com/questions/8273/… – Peter.O Feb 28 '11 at 18:02
  • @fred: It could be a seg fault arising from some internal buffer overflow, or it could be some OS limit being exceeded and the program not handling the error condition gracefully. Note that the expansion is done by the shell, not the terminal. Maybe your terminal programs have a "don't close on shell exit" setting? This way you might see how the shell exits. – Charles Stewart Mar 1 '11 at 7:14

I guess this expansion is not designed to be used that way. The crash indicates a bug, surely, but rarely triggered one.

How practical do you think is it to feed billion of consecutive integers to anything?

  • 2
    It is not only practical, it is essential when you need it... Are the designers of seq impractical? it can go orders of magnitude higher... Is it practical? absolutely (when you need it), Is it rare? I don't know, but I suspect so.. but a truck on the highway you don't see is also rare, but it is quite important :) ... However, I need it now, and I'm looking for the best option... Because of this 'integer sequence' crashing, it has triggered a broader question.. "What governs the limits of shell brace expansion?" – Peter.O Feb 28 '11 at 7:06
  • @alex: This isn't really an answer to the question, but a way of suggesting that the question is not worth asking. – iconoclast Jul 14 '11 at 20:23
  • 1
    This isn't really a comment either. – alex Jul 15 '11 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.