この例では整数シーケンスの拡張について言及していますが、おそらく（？）この制限は中括弧拡張のすべての側面に関連しています。このより一般的な点にも興味があります。
seq中括弧拡張は{1..n}より長い整数シーケンスを処理するようです（少なくともこの場合はそうです）。
たとえば、 'seq -f @%12.0f 1 1000000000 >/dev/null' .. 14m 04sで10億に拡張されました。
しかし、echo {1..10000000000} >/dev/null「gnome-terminal」と「konsole」では、CLIがクラッシュします（...こんにちはターミナルセッション！）
整数シーケンスの中かっこ拡張で得られる最高は約{1..15000000}.. 1,500万個に過ぎません。
これは中括弧拡張自体の制限ですか、それとも拡張echoデータを処理する方法の制限ですか？これは、利用可能なRAMをすべて使用したために発生しているようですが、swap現在はその領域を使用しているとします。
さらに、（しかし）この15,000,000の整数シーケンスは echo {..}57.0秒かかりますが、seq12.7秒しかかかりません。
答え1
echo {1..5}コマンドを展開し、echo 1 2 3 4 5一般的な方法で展開します。これはseq 1 1000000000 >/dev/null、引数の多いコマンドには拡張されないものとはまったく異なります。
それは次のとおりですecho $(seq 1 1000000000)。これが同じように壊れていると思いますか？
あなたが経験している問題は、Unixが常に厳しい大きなコマンドを処理することに関連しています。つまり、コマンド文字列の処理に関連する一般的な問題です。これはPerlが解決するために書かれた問題の1つです。
それにもかかわらず、私は丁寧で有益なバグレポートを提出します。これは興味深い議論を引き起こす可能性があります。
答え2
この拡張は、このように使用するように設計されていないようです。衝突は間違いなくバグを示していますが、バグを引き起こすことはほとんどありません。
何十億もの連続した整数を何でも入力することがどれほど実用的だと思いますか？