奇怪的Windows DIR命令行为

在找到一个名字中的数字的文件时,我偶然发现了这一点.当我输入：

号*号*

(其中number表示0到9之间的任何数字,星号和数字之间没有空格)

在cmd.exe命令提示符下,它返回各种文件不出现在任何符合搜索条件.奇怪的是,根据目录,一些数字将会工作而不是其他数据.例如,在与网站相关联的目录中,我键入以下内容：

dir *4*

返回的是：

Directory of C:\ampps\www\includes\pages 

04/30/2012  03:55 PM               153 inventory_list_retrieve.PHP
06/18/2012  11:17 AM             6,756 ix.html
06/19/2012  01:47 PM           257,501 jquery.1.7.1.js
               3 File(s)        264,410 bytes
               0 Dir(s)  362,280,906,752 bytes free

这对我来说没有任何意义.任何线索？

由于DIR命令通常与批处理程序中的FOR相结合,所以在stackOverflow中提出了这个问题.如果使用DIR命令,奇怪的DIR行为似乎使批处理程序潜在地不可靠.

编辑：(附加说明).虽然已经过了很多时间,但我发现了另一个怪癖,几乎花了我很多的工作.我想删除特定目录树中的所有.htm文件.我才意识到* .htm匹配.html文件.另外,* .man匹配.manifest,可能还有其他的.删除该特定目录中的所有.html文件将至少令人不安.

命令提示符下的通配符与长文件名和短“8.3”名匹配,如果存在.这可以产生惊喜.

要查看短名称,请使用/ X选项进行DIR命令.

请注意,这种行为不是特定于DIR命令的,而是可以导致在任何命令(如DEL)上通配符匹配超过预期的其他(通常令人不快)的惊喜.

与* nix shell不同,使用匹配名称列表替换文件模式在每个命令中实现,而不是由shell本身实现.这可能意味着不同的命令可以实现不同的通配符模式规则,但实际上这是非常罕见的,因为Windows提供了API调用来搜索与一个模式匹配的文件的目录,大多数程序以明显的方式使用这些调用.对于使用“常用”工具以C或C编写的程序,该扩展由C运行时库“免费”使用Windows API提供.

该问题的Windows API是FindFirstFile()及其近亲FindFirstFileEx(),FindNextFile()和FindClose().

奇怪的是,虽然FindFirstFile()的文档将其lpFileName参数描述为“目录或路径”,文件名称可以包含通配符,例如星号(*)或问号(？)“,但它从未实际定义什么*和？字符意思

文件模式的确切含义在20世纪70年代早期的CP/M操作系统中具有很大的影响(有些可能会说“直接复制”代替“影响”)MSDOS的设计.这导致了一些“有趣”的文物和行为.在2007年的this blog post中描述了DOS的一些这方面,Raymond描述了DOS中实现的文件模式.

奇怪的Windows DIR命令行为

相关文章