qzwqzw

回复 9# shelluserwlb


    关键问题在于对%，和！扩展顺序的理解

在cmd中，%的扩展是优先于其他特殊字符的
%%会扩展成%
所以
%%i会扩展成%i

所以
for /l %%i in (0,1,3) do call echo %%!ok:~%%i,1!%%
首先被扩展成以下的结果
for /L %i in (0 1 3) do call echo %!ok:~%i,1!%

然后for先对命令字句中可替换参数%i进行扩展
call echo %!ok:~0,1!%
call echo %!ok:~1,1!%
call echo %!ok:~2,1!%
call echo %!ok:~3,1!%

然后for再对命令字句中的延迟变量进行扩展
call echo %a%
call echo %b%
call echo %c%
call echo %d%

然后call再对命令中环境变量进行扩展
echo aaaaa
echo bbbbb
echo cccccc
echo ddddd

qzwqzw

回复 11# amwfjhh


    这里%ok:~%%i,1%按说是一个无效变量，但回显开启发现它直接将其初始化成了ok的值，导致行行了几次!abcd!，无此变量，故显示ECHO状态，有点莫名其妙。

实际上cmd是将%ok:~%%i,1%理解成了两个环境变量扩展
一个是%ok:~%
因为~后没有跟数字
照道理应该是无效的
但是cmd容忍了这个错误
用默认的~0做了扩展

另一个是%i,1%
因为不存在i,1的变量
所以扩展为空

批处理脚本中解释%的机制是就近匹配
第一个%后紧接着就会找第二个百分号
如果第二个字符就是
则扩展为%
如果隔几个字符找到%
则将中间的字符理解为环境变量名进行扩展

for对%扩展机制要更为复杂一些
将in关键字前的%理解为可替换参数的定义
将do关键字后的%理解为可替换参数的引用

但是在cmd命令行中
%的扩展可能有些不同
这源于命令行环境与批处理环境预处理机制的不同
echo %%path%%

而在DOS命令行中
则保持了与批处理一样的扩展机制

qzwqzw

回复 15# amwfjhh


    突然想到对于论坛对于echo命令分割符的讨论贴子了，echo命令为何会有那么多的参数分割符，因为它是内部命令，说白了，内部命令整条命令（包括参数）也对于CMD来说，也是一个参数啊，所以它必须提前对于一般程序的默认处理作下改变，所以平时用的"echo[空格]参数"，这里面的空格，跟我们用外部命令的空格，猜想已经不是同一概念了（只是它“恰巧”也提供了一个空格的分割符，以使其符合大多数人的使用习惯），这样CMD才能在一个参数中切割出不同的部分来调用相应的函数，表现出执行了一条命令的样子……

很有意思的见解
不过有些内容我不太苟同
如果你仔细看过Demon关于预处理以及echo的分析帖的话
就会理解
无论是内部命令还是外部命令
像空格、水平制表符等一般分隔符都是通用的

而对于+[].等字符
其实cmd并不视其为分隔符
只是为了尽可能兼容一些怪异的用户习惯
想尽办法做的FindAndFix而已
因为只是一些Fix
所以大多数命令甚至很多内部命令
对这些伪分隔符字符是不“认账”的

qzwqzw

你测试的这种情况应该是explorer.exe来传递的命令行参数
它应该是调用MSVCRT的标准函数来实现命令行词法切分
这些标准函数通常都会以空格作为参数分隔符

qzwqzw

回复 22# amwfjhh


    win下的程序，应该都是统一的参数分割标准，CMD也是一个WIN程序，其本身也是这样，但是在CMD运行环境下调用内部命令或者外部命令，按照常情也应该像在WIN下调用程序一样，那么问题来了，对于一个输入字符串，如何解析，势必参照WIN下的处理方式，于是有了那一系列的处理，至于额外的规则，说不定当初写CMD的某个人或者某个团队中的核心人物，想恶作剧一把，于是就产生了现在看起来相对于WIN下的参数方式有点“非主流”的切割符列表。

所谓“额外的规则”
初衷显示不是开发者的恶作剧
而是为了保持向下兼容
cmd缘起于DOS
许多命令行习惯必然从DOS获得继承
而在DOS下
空格与分号、等号等同是“主流”分隔符
而这些分隔符的由来
同时是为了兼容初期的DOS
乃至类似的命令行环境的用户习惯
保持用户界面友好
这是MSDOS之所以流行的主因