qzwqzw

不久前在查询关于usebackq的bug信息
结果就搜索了这篇帖子
记起某个茬通过评分提交原作者至今尚无反馈
索性就准备写在这里
请其它版主代为修正

当回过头来再细看那篇经典教程时
不免又发现了一些瑕疵
说是错误也未必尽然
只是确有推敲之处
既成经典就当尽求完美
鼓励怀疑提倡讨论
不可因作者的身份就谨言慎行
否则就迷失了我们讨论的本来目的

不知道为什么版主要求的规范里还要求写帐号
帖子旁边的作者不算吗？
不过还是怎么要求怎么来吧
以下按行文顺序列出我所找到的BUG

1.qzwqzw
2.错误之处：3楼，for %I in (command1) do command2
3.改正：FOR %variable IN (set) DO command [command-parameters]，其它段落中相关联的词句和术语建议同时修改
4.理由：
CMD的帮助有时还是靠得住的
况且命令文档的书写自然形成了一定的体例
像楼主的写法
说范式不像范式，因为有%%I
说例句又不像例句，因为有command1/command2
而且无法理解作者为何要将for的set换成command1

qzwqzw

1.qzwqzw
2.错误之处：4楼，所有的对象，无论是文件、窗体、还是控件，在所有的非机器语言看来，无外乎都是形如"c:\test.txt"、"CWnd"之类的文本信息...
3.改正：建议整段删除
4.理由：很多对象并非是单纯的文本信息，甚至大部分对象都不是纯文本信息，而是二进制数据，所以作者举的例子并不是很好

qzwqzw

1.qzwqzw
2.错误之处：4楼，这段代码，主要是让你树立这样一种观念：读取文本文件的内容，请使用 for /f 语句！
3.改正：将“读取文本文件的内容”改为“逐行分析文本文件的内容”
4.理由：读取文本文件内容的方法命令有很多，比如重定向输入，又比如type/more/find/sort等命令

qzwqzw

1.qzwqzw
2.错误之处：4楼，在这里，我们引入了一个新的开关："delims=，"
3.改正：将“开关”改为“选项”，其它相关联内容建议同时修改
4.理由：同3楼帖，windows习惯上将命令之后以/或者-起始的命令行参数叫做开关（switch），而对于for /f 之后的控制信息，系统文档使用的是“选项/选项组”（"options"）

qzwqzw

这也算是本人所发现的第一个BUG

1.qzwqzw
2.错误之处：4楼，使用 for /f "eol=" 语句，也就是说，强制指定字符为空，就像对付delims=一样。
3.改正：建议整段删除
4.理由：以前有过讨论，"eol="会指定双引号为行注释字符，所以目前我的取消行注释字符的近似方法，使用eol指定另外一个文本中很难出现的字符作为行注释字符，比如ANSI字符集中控制区字符或者Unicode字符集中的偏僻字符

for /f "eol=" %f in ("""not echo") do @echo %f
复制代码

qzwqzw

1.qzwqzw
2.错误之处：5楼，首先，把一条完整的语句读入内存中（不管这条语句有多少行，它们都会被一起读入），然后，识别出哪些部分是命令关键字，哪些是开关、哪些是参数，哪些是变量引用……如果代码语法有误，则给出错误提示或退出批处理环境；如果顺利通过，接下来，就把该条语句中所有被引用的变量及变量两边的百分号对，用这条语句被读入内存之就已经赋予该变量的具体值来替换
3.改正：将“然后，识别出....顺利通过"删除
4.理由：

set "cs=&"
set/p=test1<nul%cs%echo test2

set sw=/l
for %sw% %%i in (1,1,3) do echo %%i--

set cmd=errorcmd
%cmd%

set errsw=/k
dir %errsw%
复制代码

这个问题前几天就发现了
但是为了寻求理论上的确认花费了一些时间
经过数次跟踪分析
发现CMD的词法分析机制异常复杂
为此找了一些NT4下的cmd资料
NT4的CMD不支持变量延迟扩展和很多扩展特性
分析起来相对简单
但仍然没有得到确切的结论

大致可以得出的结论是
CMD首先分析了语句符号（包括() 和 @）
以及命令连接符号（顺序大致是& || && |）
再次分析for / if / rem / 其它命令 / 下级语句
在这些分析的过程中
如果遇到变量符号%则随时进行分析扩展

所以说cmd变量扩展和词法切分是混合进行的
很多特殊符号() | & 等会导致词法切分的退字符动作
%等符号会将缓冲区的字符指针重新定位
也就是说它们都会将命令缓冲区的Token串进行重整
以便在下一步的词法分析中可以继续对扩展结果进行切分和解析

qzwqzw

回复 17# cjiabing
没想到
我那天的“梦话”都会有人回复
你所说的几点很有条理
我总体上是同意的

只是cmd的语句分析自有其复杂之处
他的词法分析和解析调用动作不会完全依照那个流程
这主要包括对嵌套的（）的处理
对& | && || 的处理