bc -l 默认不设 scale 时除法返回整数，三角函数以弧度为输入，角度需转弧度（如30°→30a(1)4/180），ibase/obase顺序错误会导致进制解析异常，且-l下%运算不可靠。
直接用 bc -l，但必须注意数学库加载后默认行为变化——不设 scale 时除法结果仍是整数，而三角函数等要求弧度输入，不是角度。
为什么 echo "sin(30)" | bc -l 返回接近 0.5 的值但其实是错的
因为 bc 的 s(x) 函数（正弦）接受的是**弧度**，不是角度。30 被当作 30 弧度（≈ 1718°），不是你想算的 30°。正确写法要先转角度为弧度：30 * a(1) * 4 / 180（a(1) 是 π/4，所以 a(1)*4 ≈ π）。实际可这样算：
echo "scale=6; s(30 * a(1) * 4 / 180)" | bc -l
常见错误现象：结果明显偏离预期（比如 sin(30°) 得到 −0.988…），就是没转弧度。
-
a(1)是反正切(1)，即 π/4；乘以 4 得 π - 角度转弧度公式是
deg * π / 180，所以用deg * a(1) * 4 / 180 -
scale必须显式设置，否则小数位数可能不足（-l默认 scale=20，但输出仍可能截断）
bc -l 下做除法却得到整数？
即使加了 -l，bc 仍默认按 scale=0 执行除法，除非你显式指定。例如：
echo "5/3" | bc -l # 输出 1（不是 1.666…）
这是因为 -l 只加载函数库，不改变 scale 默认值。必须手动设：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
echo "scale=10; 5/3" | bc -l # 输出 1.6666666666
- 不加
scale=，所有除法、开方等都只返回整数部分 -
scale影响所有后续运算，包括函数返回值（如sqrt()） - 若在管道中连续多条语句，
scale设置只需一次，作用域覆盖整条输入
进制转换 + 科学计算混用时的顺序陷阱
当同时用 ibase（输入进制）和 obase（输出进制）与数学函数时，顺序很关键：obase 必须写在 ibase 前面，否则 ibase 后的数字会被按旧进制解析。例如想把十六进制 CFFF 转十进制再开平方：
echo "obase=10; ibase=16; sqrt(CFFF)" | bc -l
如果写成 "ibase=16; obase=10; ..."，obase=10 中的 10 会被当成十六进制 → 十进制的 16，导致输出变成十六进制而非十进制。
-
ibase和obase都是“立即生效”的变量，顺序即执行顺序 - 数学函数（如
sqrt）的参数始终按当前ibase解析，所以CFFF必须在ibase=16生效后才出现 - 一旦设了非十进制
ibase，所有后续数字（包括scale=后的值）都按该进制读 —— 所以scale建议总用十进制写（即写scale=10，别写scale=A）
取余 % 运算不能和 -l 共存
这是最易踩的坑：bc -l 下 % 行为异常，例如 echo "10%3" | bc -l 可能返回 0 或报错。原因是 -l 改变了内部数值表示，使取余逻辑失效。
解决方法只有两个：
- 科学计算中需取余 → 分开处理：先用不带
-l的bc算余数，再用-l做浮点部分 - 或改用整数部分截断模拟，如
10 - (10/3)*3（但要注意scale和整除精度）
真正复杂点在于：很多脚本会把整个表达式一股脑喂给 bc -l，却没意识到其中某个子表达式依赖 % —— 它不会报错，但结果不可信。
