Bash脚本中HDFS路径通配符失效问题排查

嘿，我明白你遇到的困惑了——本地路径的通配符用得好好的，换成HDFS路径就失效，这事儿确实容易懵。咱们一步步拆解问题，然后解决它。

先搞懂本地和HDFS通配符的处理差异 #

本地文件系统的通配符（比如*）是由你的shell（比如bash）直接处理的：shell会先扫描本地文件系统，把通配符替换成匹配的文件名，再传给ls这类命令。这就是为什么你本地的~/some*能正确展开成some-file.txt。

但HDFS路径不一样：你的shell根本访问不到HDFS的文件元数据，所以它没法替你解析HDFS路径里的通配符。这时候通配符的处理工作是交给hdfs dfs命令自己来做的——但这里有个坑，shell会先“插一脚”，尝试在本地文件系统匹配通配符，找不到的话才会原样传给HDFS命令。

你的脚本问题出在哪？ #

看你的测试脚本：

APPJAR=hdfs:///user/myusername/myproject/lib/myproject*.jar
echo $(hdfs dfs -ls $APPJAR)
echo $APPJAR

当你执行hdfs dfs -ls $APPJAR时，shell会先在本地找有没有匹配myproject*.jar的文件。显然本地没有，所以它把带通配符的路径原封不动传给hdfs dfs -ls。理论上HDFS命令应该能解析这个通配符，但如果没生效，大概率是这两个原因：

• HDFS路径拼写错误（比如用户名、目录名写错了）；
• HDFS目标路径下根本没有匹配myproject*.jar的文件；
• 少数情况：本地恰好有个同名的文件，shell把它替换了，导致传给HDFS的是本地文件名而不是带通配符的路径。

解决办法 #

方法1：用引号包裹变量，阻止shell的多余处理 #

最稳妥的方式是把变量用双引号括起来，让shell直接把完整的带通配符的路径传给hdfs dfs命令，由HDFS自己解析：

echo $(hdfs dfs -ls "$APPJAR")

这样shell就不会在本地瞎找匹配的文件了，HDFS命令能拿到完整的通配符路径，自然能正确展开。

方法2：直接在命令中使用通配符（如果不需要复用变量） #

如果这个路径只在一处使用，没必要赋值给变量，直接写在命令里更简单：

echo $(hdfs dfs -ls hdfs:///user/myusername/myproject/lib/myproject*.jar)

这种方式下，shell同样会尝试本地匹配，但找不到的话就把通配符传给HDFS命令，效果和方法1一致。

方法3：先验证HDFS路径本身是否有效 #

先手动执行这条命令，确认HDFS上确实有匹配的文件：

hdfs dfs -ls hdfs:///user/myusername/myproject/lib/myproject*.jar

如果这条命令能返回预期的文件列表，那就是脚本中变量传递的问题；如果不能，那你得先检查路径拼写或者文件是否存在。

内容的提问来源于stack exchange，提问作者Logan Yang