Bash数字限制？

Question

我之前在stackoverflow上提出了一个问题，涉及从文本文件中获取大素数并将其放入另一个文件中。脚本本应该获取2 ^ 32及其以上的每个质数，但由于某种原因，脚本停止工作了。

#!/bin/bash
n=4294967296
last=0
while read number
    do
    if [ $last -gt $n ]
    then break
    fi
    echo $number
last=$number
done < primes.txt > primes2.txt

最终它循环遍历了这11个数字：

4232004449  
4232004479  
4232004493  
4232004509  
4232004527  
4232004533  
4232004559  
4232004589  
4232004593  
4232004613  
004437

原始文件中没有004437，而我的bash可以处理超过8999999999999999999的数字。

是否有人知道为什么会出现这种情况？

64位Ubuntu 10.04，16GB RAM，8核@3.60 GHz
GNU bash，版本4.1.5（1）-release（x86_64-pc-linux-gnu）

更新：

下载并编译由jfgagne提供的“修复”bash，并在我的bash脚本中链接到它时，它在完全相同的位置出错。使用更快的perl等效工具，在原始素数问题中，我从ls -al获取了一些文件大小:

        11  next_prime (just to make sure this was counting bytes accurately)
2147483659  primes2.txt
2147483670  one_too_many

2147483659 = 2^31 + 11

下一个质数的大小为4232004631，共11个字节，其中包含了所有小于4232004613的质数。我还意识到，004437来自于错误循环底部的质数末尾（4232004437）。似乎有些东西在试图前进，但卡住了。

- user1846065

---

请参考此帖子：Bash脚本和大文件（bug）：使用重定向从read内置输入会产生意外结果。 - jfg956

太棒了，我在Linux中找到了我的第一个bug。明天我会实施修复。谢谢你提供的链接。 - user1846065

似乎那不是问题所在。我从git下载了tar文件，在我的桌面上编译它，将其链接到bash脚本中，然后再次运行它。我马上会更新我的问题。 - user1846065

它可能是EXT2或4。我不得不升级我的操作系统，所以我不再拥有这个系统了，但基本上它是一个干净的Ubuntu 10.4安装，安装了像vim和gparted这样的东西。 - user1846065

不，如果您使用更新的Bash，则足够了，它们始终具有64位有符号整数变量（即使在32位架构上）。 - peterh

Answer 1

不，它与您操作系统的位数无关。它取决于bash源代码中的一个简单声明。

自2002年以来，此声明为__int64_t。自那时起，bash版本 >= 3.00始终使用64位整数变量，并且它不依赖于架构！它仅取决于bash版本。

早期的bash版本始终使用32位整数，即使在64位操作系统上也是如此。

- peterh