【问题标题】:why perl testing dir -d " " on windows returns true? bug or not?为什么 perl 在 windows 上测试 dir -d "" 返回 true?错误与否?
【发布时间】:2014-05-10 21:01:53
【问题描述】:

在 Windows 上测试空格字符串目录时 perl 返回 true 有什么解释吗? 在 Windows7 上运行:

  perl -e "print qq{found\n} if -d qq{ }"

你会得到输出:found

但相同的 perl 代码在 Linux 上返回 false。

在 Windows 上的 perl 5.8 和草莓 perl 5.18 上测试

这是一个错误还是有非常规的推理?

【问题讨论】:

  • perl -wle"print for stat(' ')" 显示什么?
  • @ysth,16832 (040700) 用于第三个字段 ($mode),0 用于其他所有字段。
  • 无法创建具有该名称的文件(“没有这样的文件或目录”)。
  • 我认为这是一个错误。我不认为这是新的。我似乎记得几年前遇到过这个。
  • 常用的做法是使用“if -d $dirname”来测试目录是否存在。但不应该用于 Windows,除非此错误已修复或添加额外的测试以防止空格字符串。为什么这个bug这么久都没有修复?

标签: windows perl


【解决方案1】:

在 windows 下,任何内部尝试测试文件或目录是否存在的 perl 操作都使用 Win32 函数CreateFile。在 Windows 下,以空格结尾的文件名是不合法的(尽管没有明确记录),并且出于某种奇怪的原因,CreateFile 函数在尝试打开文件/目录之前会在内部删除所有尾随空格。

由于以空格开头的名称看起来像一个相对路径,因此空格首先会附加到您当前的工作目录,但随后会被 Win32 函数在内部忽略。这会导致目录测试看到您当前的目录并报告成功。

perl stat 函数然后继续获取附加信息,并且似乎在某处以不同方式处理尾随空格,因此无法获得任何进一步的信息。然而,它似乎明确地保留了 stat 结果集的 mode 属性,因为它之前已经推断出存在一个目录。

所以是的,我认为这是 perl 的 windows 端口中的错误,但修复它可能不像听起来那么容易,因为 UNC 路径、重解析点、NTFS/FAT 文件系统等有很多特殊情况. 这使得正确处理尾随空格变得相当棘手。

您最好的选择可能是在很早的时候从任何假定的目录名称中显式删除尾随空格(无论如何都需要),如果在删除后什么都没有留下,那就发牢骚。

【讨论】:

    猜你喜欢
    • 2020-12-14
    • 2012-10-06
    • 1970-01-01
    • 2016-05-03
    • 2022-11-23
    • 1970-01-01
    • 2013-02-22
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多