☰

列出目录中的文件：奇怪的输出

tag-icon • tag-icon windows command-line
列出目录中的文件：奇怪的输出

我试图列出某些目录中的文件，但得到了奇怪的结果。

这是我在命令提示符中输入的命令：dir *t.*

结果如下：

c:\test\1.1.1990.txt
c:\test\1.31.1990.txt
c:\test\1.txttxt
c:\test\11.11.2007.txtGif
c:\test\12.1.1990.txt
c:\test\12.31.1990.txt
c:\test\2.tGift
c:\test\2.txtGif
c:\test\5bbb.exeTxt
c:\test\test.txt

第 9 个输出特别奇怪：5bbb.exeTxt，考虑到我的查询，为什么我会得到这个结果？（现在我看着它，大多数结果看起来很奇怪？）例如，为什么是第二个？

有人可以解释一下吗？

我需要使用获取文件方法，我猜它以同样的方式工作，这就是我感兴趣的原因。

有关的：列出文件夹中与模式匹配的文件（堆栈溢出）

答案1

我怀疑这是因为Raymond Chen 的博客（警告-不是实际文档）。

例如，如果您的模式以 .* 结尾，则 .* 将被忽略。如果没有此规则，模式 *.* 将仅匹配包含点的文件，这可能会破坏地球上 90% 的批处理文件以及每个人的肌肉记忆，因为每个运行 Windows NT 3.1 的人都是在 *.* 代表所有文件的世界中长大的。

您的模式是*t.*，我假设 会更改为 ，*t然后匹配5bbb.exeTxt。我不确定它是如何DirectoryInfo.GetFiles工作的，为什么不测试一下呢？

看起来也许短名称也匹配，或者扩展名的前三个字符。

G:\junk\filetest>dir
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  10:01 AM    <DIR>          .
09/09/2014  10:01 AM    <DIR>          ..
09/09/2014  09:59 AM                 6 test.txtR
09/09/2014  10:01 AM                 2 test.txtrrr
               2 File(s)              8 bytes
               2 Dir(s)  162,957,000,704 bytes free

G:\junk\filetest>dir *.txt
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  09:59 AM                 6 test.txtR
09/09/2014  10:01 AM                 2 test.txtrrr
               2 File(s)              8 bytes
               0 Dir(s)  162,957,000,704 bytes free

G:\junk\filetest>dir /x *.txt
 Volume in drive G is Extended2
 Volume Serial Number is 3E2F-7A67

 Directory of G:\junk\filetest

09/09/2014  09:59 AM                 6 TEST~1.TXT   test.txtR
09/09/2014  10:01 AM                 2 TEST~2.TXT   test.txtrrr
               2 File(s)              8 bytes
               0 Dir(s)  162,957,000,704 bytes free

答案2

我认为@dsolimano（以及他的消息来源 Raymond Chen）非常接近您的问题，但可能没有给出正确的解释。经过一番思考、搜索和测试，虽然我还没有拿出实际的文档来支持这一点，但我相信我已经得出了一个相当准确的结论。

我的假设是基于域名和其他一些命名计算机资源中有些相关的行为。对于域名，末尾实际上有一个隐含的尾随点。因此www.superuser.com实际上是www.superuser.com.。经过一些测试，我的结论是 Windows API（如果不是文件系统本身）对文件名使用相同的约定。

考虑一下你给出的所有与结果匹配的文件名。如果你考虑到搜索中包含 8.3 个文件名，如下所述这里，并假设长文件名以一个点结尾和8.3 文件名末尾带有点，你会看到每个人这些文件至少有一个版本的文件名与之匹配。（请记住，*通配符是一个占位符，代表“任意数量的字符，或零个字符”。）

  • c:\test\1.1.1990.txt匹配为1.1.1990.txt.或111990~1.TXT.
  • c:\test\1.31.1990.txt匹配为1.31.1990.txt.或131199~1.TXT.
  • c:\test\1.txttxt匹配为1.txttxt.或1956B~1.TXT.
  • c:\test\11.11.2007.txtGif匹配为111120~1.TXT.
  • c:\test\12.1.1990.txt匹配为12.1.1990.txt.或12199~1.TXT.
  • c:\test\12.31.1990.txt匹配为12.31.1990.txt或123119~1.TXT.
  • c:\test\2.tGift匹配为2.tGift.
  • c:\test\2.txtGif匹配为2BEFD~1.TXT.
  • c:\test\5bbb.exeTxt匹配为5bbb.exeTxt.
  • c:\test\test.txt匹配为test.txt或test.txt.

C:\test您可以通过按照如下所述创建一系列测试文件并dir *t.*再次运行来测试这一点。

  1. 扩展名以“t”结尾的文件。
  2. 名称以“t”结尾的文件。
  3. 扩展名长度超过三个字母且扩展名中的第三个字母为“t”的文件。
  4. 一些文件符合上述多个条件。
  5. 名称以“t”结尾且没有扩展名的文件。
  6. 一些文件不符合上述任何标准。

您应该看到，正如我所看到的，这dir *t.*将仅返回属于上述 1-5 类的文件。第 6 类中的文件将被排除。您还可以GetFiles使用以下命令使用 PowerShell 更直接地针对相同的文件测试该方法，您应该会看到相同的结果。

[IO.Directory]::GetFiles('C:\test','*t.*')

相关内容