WSL下Bash脚本无法正确统计文本/二进制文件数量（单独文件识别功能正常）

我太懂这种郁闷了——单独测isText工具好好的，一集成到Bash脚本里批量统计就出问题，尤其是在WSL这种跨环境场景下，大概率是批量处理时的细节没考虑到。咱们一步步来排查解决：

• 先踩实文件名和路径的基础坑
  WSL里很容易混着用Windows和Linux路径，要是你脚本里写了C:\xxx这种Windows风格路径，Bash根本处理不了，得换成WSL的Linux路径格式（比如/mnt/c/your-target-folder）。另外，文件名带空格、!@#这类特殊字符的话，裸写路径会被Bash拆成多个参数，调用isText的时候一定要把文件路径用双引号包死：

  ./isText "$file"
  

  这是批量处理文件时最容易忽略的致命细节！

• 换用靠谱的文件遍历姿势
  很多人会用for file in $(find . -type f)遍历文件，但这种方式碰到带空格的文件名直接GG——Bash会把空格当成分隔符，把一个完整文件名拆成多个“假文件”处理。推荐用find的-print0配合read -d ''的组合，完美兼容所有特殊文件名：

  text_count=0
  binary_count=0
  
  # 遍历所有普通文件，排除软链接，处理特殊文件名
  find . -type f -not -type l -print0 | while IFS= read -r -d '' file; do
      # 先判断文件是否可读，避免权限问题干扰结果
      if [ -r "$file" ]; then
          result=$(./isText "$file")
          # 严格匹配结果，避免isText输出多余内容干扰
          if [ "$result" = "1" ]; then
              ((text_count++))
          elif [ "$result" = "0" ]; then
              ((binary_count++))
          fi
      fi
  done
  
  echo "文本文件总数: $text_count"
  echo "二进制文件总数: $binary_count"
  

• 检查isText的输出是否“干净”
  虽然单独运行看起来正常，但有没有可能你的C程序偷偷输出了多余内容？比如调试用的打印语句、换行符之外的空白？可以用./isText your-test-file | cat -A看看输出——正常应该只有1$或0$（$是换行符标记）。如果有其他杂字符，那得修改C程序，确保只输出1或0，没有任何额外输出，不然脚本里的result变量会拿到错误值，统计自然乱套。

• 排查WSL的文件权限小坑
  Windows下的文件挂载到WSL后，有时候权限会异常（比如显示755但实际不可读），在脚本里加个-r "$file"的判断，跳过不可读的文件，避免因为权限不足导致isText输出异常，影响统计结果。

• 加调试信息精准定位问题
  要是还找不到症结，就在脚本里加一行调试输出，看看每个文件的处理结果：

  result=$(./isText "$file")
  echo "正在处理: $file | isText返回结果: $result"
  

  跑一遍脚本，就能直接看到哪个文件的结果不对劲，针对性排查那个文件的情况就行。

备注：内容来源于stack exchange，提问作者Dinis Pereira