我写了十年的shell脚本，今天才真正搞明白减法该怎么写。不是`expr $a - $b`那种玩具，而是处理真实数据时的那些坑。

上周处理一份服务器日志，要计算两次请求的时间差。文件里存的是epoch毫秒数，1324567890123这种。我顺手就写了`echo $((end - start))`，结果输出负数。查了半天，发现是某行日志的结束时间戳比开始时间戳早了整整一天。数据采集器时钟漂移了。

这就是shell减法的第一个真相：结果的正负只取决于你的数据是否干净。脚本不会帮你校验，它只会忠实地执行减法，然后输出一个可能让你困惑的负数。

真正让我改观的是处理大数的时候。`$(( ))`用的是64位有符号整数，最大能到9223372036854775807。看起来够用对吧？直到我遇到一个需求：计算两个纳秒级时间戳的差值，用来分析微服务调用延迟。纳秒时间戳是19位数，直接减会溢出，输出一个看起来完全随机的巨大数字。

解法其实很笨——先转成秒和纳秒分开处理，或者用`bc`。但`bc`慢，在循环里跑一万次能让你怀疑人生。后来我学聪明了，用`awk`的浮点运算，`awk 'BEGIN{ print 1234567890123456789 - 1234567890123456780}'`，精度够，速度也还行。

还有个细节很多人不知道：shell减法的空格敏感。`$((a - b))`和`$((a-b))`结果一样，但如果你写成`$((a- b))`，某些老版本sh会直接报语法错误。我踩过这个坑，在CentOS 6上跑得好好的脚本，换到Debian 8就挂了。后来统一用`$((a-b))`不带空格，反而更安全。

别小看减法里的变量类型。shell里所有变量本质都是字符串，`$(( ))`会强制转成整数。如果你从文件里读到的数字带个换行符，比如`value=$(cat file)`，那`$((value-1))`会算出什么？它会忽略末尾的换行，正常计算。但要是文件里带个回车符（Windows格式），那就完蛋了，直接报错。我处理过一批从Windows服务器同步过来的日志，每次减法都报"value too great for base"，排查了半天才发现是\r在捣乱。

最让我意外的是，shell减法在处理负数时有个隐藏行为。如果你写`$(( -5 - 3 ))`，结果-8没问题。但如果你写`$(( - 5 - 3 ))`，空格在负号和数字之间，某些shell会解析成"减 5 减 3"，结果变成-8以外的数。具体是多少取决于上下文，我遇到过一次输出-2的情况，至今没完全搞懂解析规则。

说到底，shell减法不是数学课上的减法。它是文本处理的一部分，你得先保证输入是干净的整数，没有隐藏字符，没有浮点，没有超出范围。然后你才能放心地写`delta=$((end-start))`。

现在我的脚本里都有个预处理函数，先`tr -d '\r'`，再`grep -E '^[0-9]+$'`过滤，最后才做减法。麻烦是麻烦点，但再也没出过负数或溢出的幺蛾子。如果你也在写类似的时间计算脚本，建议先花十分钟检查数据的纯净度，比事后debug省事得多。