奇怪的Windows DIR命令行为 [英] Strange Windows DIR command behavior

问题描述

当我找到一个名字中的数字的文件时，我偶然发现了这个。当我输入：

dir * 号码 *

（其中number代表从0到9，星号和号码之间没有空格）

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

  dir * 4 * 
  

，返回的是：

 
 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文件264,410字节
 0 Dir（s）362,280,906,752个字节的空闲
 

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

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

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

解决方案

命令提示符下的通配符与长文件名和短8.3名匹配，如果存在。这可能会产生惊喜。

要查看短名称，请使用<$ c $ / X 选项 DIR 命令。

请注意，这种行为不是以 DIR 命令，当通配符匹配超过任何命令的预期值（例如 DEL ）时，可能会导致其他（通常令人不快）的惊喜。

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

Windows有问题的API是 FindFirstFile（） 及其近亲 FindFirstFileEx（） ， FindNextFile（） ， a href =http://msdn.microsoft.com/en-us/library/windows/desktop/aa364413(v=vs.85).aspx =noreferrer> FindClose（） 。

奇怪的是，虽然 FindFirstFile（）的文档描述其lpFileName参数为目录或路径，文件名可以包含通配符，例如，一个星号（ * ）或问号（？）它从来没有实际定义什么是 * 和？字符意味着。

文件模式的确切含义1970年代初期 CP / M 操作系统的历史记录受到很大影响（有些可能说直接复制代替影响这里）MSDOS的设计。这导致了一些有趣的文物和行为。其中一些在DOS端的频谱在这个博客从2007年起，Raymond描述了DOS中实现文件模式的方式。

I discovered this quite by accident while looking for a file with a number in the name. When I type:

dir *number*

(where number represents any number from 0 to 9 and with no spaces between the asterisks and the number)

at the cmd.exe command prompt, it returns various files do not appear in any to fit the search criteria. What's weird, is that depending on the directory, some numbers will work and not others. An example is, in a directory associated with a website, I type the following:

dir *4*

and what is returned is:

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

That just doesn't make any sense to me. Any clue?

The question is posed on stackOverflow because the DIR command is often combined with FOR in batch programs. The strange DIR behavior would seem to make batch programs potentially unreliable if they use the DIR command.

Edit: (additional note). Though much time has passed, I discovered another quirk with this that almost cost me a lot of work. I wanted to delete all .htm files in a particular directory tree. I realized just before doing it that *.htm matches .html files as well. Also, *.man matches .manifest, and there are probably others. Deleting all .html files in that particular directory would have been upsetting to say the least.

解决方案

Wild cards at the command prompt are matched against both the long file name and the short "8.3" name if one is present. This can produce surprises.

To see the short names, use the /X option to the DIR command.

Note that this behavior is not in any way specific to the DIR command, and can lead to other (often unpleasant) surprises when a wild card matches more than expected on any command, such as DEL.

Unlike in *nix shells, replacement of a file pattern with the list of matching names is implemented within each command and not implemented by the shell itself. This can mean that different commands could implement different wild card pattern rules, but in practice this is quite rare as Windows provides API calls to search a directory for files that match a pattern and most programs use those calls in the obvious way. For programs written in C or C++ using the "usual" tools, that expansion is provided "for free" by the C runtime library, using the Windows API.

The Windows API in question is FindFirstFile() and its close relatives FindFirstFileEx(), FindNextFile(), and FindClose().

Oddly, although the documentation for FindFirstFile() describes its lpFileName parameter as "directory or path, and the file name, which can include wildcard characters, for example, an asterisk (*) or a question mark (?)" it never actually defines what the * and ? characters mean.

The exact meaning of the file pattern has history in the CP/M operating system dating from the early 1970s that strongly influenced (some might say "was directly copied" in place of "influenced" here) the design of MSDOS. This has resulted in a number of "interesting" artifacts and behaviors. Some of this at the DOS end of the spectrum is described at this blog post from 2007 where Raymond describes exactly how file patters were implemented in DOS.

这篇关于奇怪的Windows DIR命令行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！