wttr.in天气服务在终端脚本中的集成问题分析

问题背景

在使用wttr.in天气服务时，用户遇到了一个有趣的现象：直接在终端执行curl命令可以正常获取天气信息，但将同样的命令集成到.zshrc配置文件中却无法正常工作。具体表现为脚本中显示"Weather unavailable now!!!"的错误提示，而实际上通过临时文件可以看到天气数据已被正确获取。

技术分析

现象本质

这个问题实际上反映了脚本逻辑与数据获取之间的时序关系处理不当。通过深入分析，我们可以发现几个关键点：

1. 脚本中使用了readarray命令将临时文件内容读入数组变量
2. 随后立即删除了临时文件
3. 但在条件判断时却使用了错误的数组索引（原脚本检查的是aWeather[2]而非aWeather[0]）

根本原因

问题的核心在于脚本中的条件判断逻辑与数据实际存储位置不匹配。当使用readarray将文件内容读入数组时：

• 文件的第一行会存储在数组索引0的位置
• 第二行存储在索引1，以此类推
• 原脚本检查aWeather[2]导致条件判断失败

解决方案

方法一：修正数组索引

最简单的解决方案是修改条件判断，检查正确的数组索引：

if [[ "${aWeather[0]}" == "Weather report:"* ]] ; then

方法二：使用grep命令

更健壮的解决方案是使用grep直接检查文件内容，避免数组索引的问题：

if grep -q 'Weather report:' /tmp/now-weather; then

这种方法不需要先将内容读入数组，直接检查文件内容，逻辑更加清晰。

方法三：优化脚本结构

对于生产环境使用，建议采用更完善的脚本结构：

weather_data=$(curl -s --max-time 3 wttr.in/Belgrade?2)
if [[ "$weather_data" =~ "Weather report:" ]]; then
    echo "$weather_data"
else
    # 错误处理逻辑
fi

这种方法完全避免了临时文件的使用，更加简洁高效。

最佳实践建议

1. 避免不必要的临时文件：现代shell脚本完全可以在内存中处理这类数据，不需要写入临时文件
2. 使用更可靠的条件判断：正则表达式匹配比简单的字符串前缀检查更健壮
3. 考虑超时处理：网络请求应该设置合理的超时时间，避免脚本挂起
4. 错误处理：应该提供有意义的错误信息，帮助用户诊断问题

总结

wttr.in作为一个优秀的终端天气服务，其API本身工作正常。集成到shell脚本中出现问题时，应该首先检查脚本逻辑是否正确处理了API返回的数据。通过修正数组索引或改用更可靠的检查方法，可以轻松解决这类集成问题。对于shell脚本开发，遵循"避免临时文件"、"健壮的错误处理"等原则，可以编写出更可靠的脚本。