中国DOS联盟

To All:

最近，在与 namejm 兄讨论完善一个关于定期备份的批处理时，遇到了一个问题，在此提出请各位指教。

在使用 cmd /f:on 开启自动完成特性后发现，如果测试目录下存在中文名的目录或文件，那么使用Ctrl+D或Ctrl+F可以正常完成这个目录或文件名，但是在继续使用Ctrl+D或Ctrl+F完成，并且下一个目录或文件的名字长度短于已完成的目录或文件名，则在显示新目录或文件的名字后，旧的目录和文件名并未完全消失，而会残留一定的痕迹。

例如，测试文件夹仅有两个文件，分别名为“长文件名”和“短名”，则在cmd /f:on 开启自动完成后，第一次按下Ctrl+F会显示“长文件名”，而第二次按下Ctrl+F会显示“短名　名”。

需要说明的是，旧文件残留的痕迹不会影响新文件的正常识别。

据分析，这应该是自动完成未能正确处理多字节字符（包括中文）文件名所造成的。在上述的测试中，第二次自动完成前，它仅仅清除了上一次显示的前三个汉字，宽度相当于6个英文字符。这似乎是cmd将上一次完成的文件名按Unicode规则将字符串长计算为4，再加上回车所代表的0d/0a两个字符，共6个。也就是说cmd以6个英文的空白字符重写了原来的文件名，以清除其显示内容，而可能未考虑到多字节字符的显示宽度要数倍于英文字符。

文件备份器
http://www.cn-dos.net/forum/viewthread.php?tid=20747&fpage=1

呵呵，在XP以上的cmd中不需要 /f:on 用 Tab / Shift+Tab 也可以实现相应功能的～～和 *nux一样～～

　　electronixtar真是个有心人，这么隐蔽的功能也找得到，PF。

　　但是用 Tab / Shift+Tab 同样会产生Ctrl+F或Ctrl+D的文件名残留问题，其他问题由于想不到测试的办法而没有发现。

　　嘿嘿，CMD真是越来越有趣了。

Re electronixtar:

大略Google搜索了一下关于自动完成的信息。

在非微软网站的信息中，所见皆明言或暗示自动完成默认是关闭的，需要cmd /f或者cmd /f:on开启。

在微软网站发布的信息中，大多文章转贴了CMD的帮助信息，“文件和目录名完成不按默认值启用。”或者“ile and Directory name completion is NOT enabled by default.”

在TechNet中找到一些有用的信息：

与自动完成相关的注册表资源有两个子键和四个表项：

HKLM\Software\Microsoft\Command Processor\CompletionChar
HKLM\Software\Microsoft\Command Processor\PathCompletionChar
HKCU\Software\Microsoft\Command Processor\CompletionChar
HKCU\Software\Microsoft\Command Processor\PathCompletionChar

正常状态下，这四个表项中只要有一项的值为控制字符，则自动完成将开启。PathCompletionChar仅完成目录名，CompletionChar完成文件名和目录名。在同时设置的情况下，HKCU的设置优先于HKLM。使用 cmd /f 后，自动完成字符将固定为Ctr+D/Ctrl+F，不受HKCU/HKLM的键值控制。

关键是默认值的问题，因为CompletionChar如果是0x0，0xD，或者大于>=0x20的字符，则自动完成将关闭（实际上是因为不符合激活条件而无法被激活）。而关于默认值的表述，在TechNet的文章中出现了矛盾。的默认值为0x9，即Tab，的默认值为0x40，即disabled。

另外，TechNet的相关文章是位于Windows Server 2003技术库的，对XP和2000不具有指向性。在我的现在XP系统中，CompletionChar为0x9，但是我的系统并非原版，而是优化过的版本，我自己也曾修改过CompletionChar。也无法排除ServicePack或者HotFix是否曾经对其进行了修改。

所以，这个问题仍然需要进一步验证。

CompletionChar Entry
http://technet2.microsoft.com/WindowsServer/en/Library/1ff97534-38d4-4cc1-86f1-c2fc2689367a1033.mspx?mfr=true

Command Processor\CompletionChar
http://technet2.microsoft.com/WindowsServer/en/Library/1ff97534-38d4-4cc1-86f1-c2fc2689367a1033.mspx?mfr=true

在很早的时候，发现在命令提示符下输入ALT+9就会得到当前目录下的某个文件名，后来才知道ALT+9就是TAB，然后依次发现ESC可以取消当前的输入，F1到F9都有不同的功能，不过大多数都与DOSKEY有关系。
后来有一天也发现了willsort所述问题，当时百思不得其解，直到有一天发现了chr(13)的作用才豁然开朗:

With Wscript.StdOut

    .Write "你好，这里是中国DOS联盟脚本版"

    Wscript.Sleep 1000

    .Write chr(13) & "error"

end With

保存为 测试.vbs 后，运行cmd，输入cscript //b //nologo就可以看到结果了。
如果不是用write方法而是用writeline方法的话会自动转到下一行而不会出现此现象。

Re 3742668:

你说的chr(13)，应该就是回车符（0x0d），在DOS的语义中，它只回车不换行，换行是由换行符控制的（0x0a；chr(10)）。

而回车、换行的排列组合不同造成了MSOS/Unix/Mac这三大系统纯文本格式的不同。MSOS是0d0a，Unix是0a，Mac是0d。

但这与自动完成的问题尚有不同。如果依照上述观点，“longname”之后的“sname”应该显示“sname e”，而非“sname”。而如果文件名中夹杂有中英文字符，你就更容易看到问题所在了。

而按照它可以按长度清除而非按区块清楚的模式来看，它最有可能采用的清除算法就是将原缓冲区字符全部置换为空白字符，或者重新生成一个由空白字符组成的等长字符串，然后再次于原位输出（类似于.Write）。而因为编译系统采用Unicode编码，不同显示宽度的英文和中文字符，有相同的字节长度和字符长度，所以出现错误就可以预料了。

都是高人啊

我认为是添加空格。