이 예에서는 정수 시퀀스의 확장을 언급하고 있지만 아마도(?) 이 제한은 중괄호 확장의 모든 측면과 관련이 있을 것입니다. 이 보다 일반적인 점에도 관심이 있습니다.
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초가 걸리지만 seq
12.7초만 걸립니다.
답변1
echo {1..5}
명령을 확장한 echo 1 2 3 4 5
다음 일반적인 방법으로 확장합니다. 이는 seq 1 1000000000 >/dev/null
인수가 많은 명령으로 확장되지 않는 와는 완전히 다릅니다 .
그것은 다음과 같습니다 echo $(seq 1 1000000000)
. 이것이 같은 방식으로 깨지는 것 같아요?
당신이 겪고 있는 문제는 Unix가 항상 까다로운 큰 명령을 처리하는 것과 관련이 있습니다. 즉, 명령 문자열을 처리하는 데 관련된 일반적인 문제입니다. 이것은 Perl이 해결하기 위해 작성된 문제 중 하나입니다.
그럼에도 불구하고 나는 정중하고 유익한 버그 보고서를 제출할 것입니다. 이는 흥미로운 토론을 촉발할 수 있습니다.
답변2
이 확장 프로그램은 이와 같이 사용하도록 설계되지 않은 것 같습니다. 충돌은 확실히 버그를 나타내지만 버그를 유발하는 경우는 거의 없습니다.
수십억 개의 연속된 정수를 무엇이든 입력하는 것이 얼마나 실용적이라고 생각하시나요?