[新手上路]批处理新手入门导读[视频教程]批处理基础视频教程[视频教程]VBS基础视频教程[批处理精品]批处理版照片整理器
[批处理精品]纯批处理备份&还原驱动[批处理精品]CMD命令50条不能说的秘密[在线下载]第三方命令行工具[在线帮助]VBScript / JScript 在线参考
返回列表 发帖
回复 15# amwfjhh


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

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

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

TOP

回复 16# qzwqzw


    嗯,谢谢指正。是我表述错误,我说的“外部命令”应该说成“开始->运行->"程序名 参数表……"”或者在“创建程序快捷方式,然后在里面指定启动参数”,这类调用;在CMD里面不管是内部命令还是外部命令处理分割符的方式应该是一样的。前者不知有人逆向跟踪过没,是否也如在CMD里面的参数读取过程一样呢?

TOP

本帖最后由 amwfjhh 于 2014-11-22 01:31 编辑

测试了一下,随意用个播放器,在运行里面运行"程序名,参数"或者建一个快捷方式,在其指向里添上",参数",两者均提示无效调用,而将","换成空格,正常执行,看来只是在CMD环境下才是对,=;等视作分割符标志,空格应是先被转义统一作为普通字符,待预处理读取完一整行(或者一整个语句块)作为参数传给宿主程序后,词法分析到关键字后再在分割符表里查关键词后有没有相应的字符,空格则正好是其中之一,从这个意义上说,它与,=;等字符具有同等意义。而不像其它程序的非CMD环境调用参数,未转义的空格直接作为参数分割符。

TOP

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

TOP

回复 19# qzwqzw


    为什么表情里面没有点赞的表情,只有文字点了,一句话说到了本质。

TOP

回复 18# amwfjhh


不知道有没有解析命令行参数的api...
但反正编译器貌似都有内置解析参数的功能吧,常见的规则大同小异,win 下空格分隔、双引号转义是起码的
具体执行的时候有一些小区别,比如 gcc 会把参数中的 * 解析成一串的文件路径,tcc 印象中是会自动去掉双引号,这些就很无奈了,只好取出原始命令行参数自行分割
至于 tab , ; = 这些分隔符,貌似不是主流,全看作者心情了

TOP

本帖最后由 amwfjhh 于 2014-11-24 12:02 编辑

win下的程序,应该都是统一的参数分割标准,CMD也是一个WIN程序,其本身也是这样,但是在CMD运行环境下调用内部命令或者外部命令,按照常情也应该像在WIN下调用程序一样,那么问题来了,对于一个输入字符串,如何解析,势必参照WIN下的处理方式,于是有了那一系列的处理,至于额外的规则,说不定当初写CMD的某个人或者某个团队中的核心人物,想恶作剧一把,于是就产生了现在看起来相对于WIN下的参数方式有点“非主流”的切割符列表。
哪天看下VC的源代码,看看能不能找到怎么处理参数事宜的。不过看一般的入口函数int main(int argc, char** args),程序名与参数也是一个字符串来的,一直在用从字符串中取参数,还没想过哪里规定的这样取参数,要进一步去看是哪里对于参数处理以及处理规则。


PS:
vc下能看到的启动过程是kernel32! 0x7c81776f==>crt0.c==>各种main()
还需要继续

TOP

回复 22# amwfjhh


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

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

TOP

我的理解是这样的:
第一次去掉%是这样的结果
echo !k%:~1,1!  

第2次直接得
~1,1

TOP

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



    第一,原来如此,里面还有如此厚重的历史气息,谢谢科普;第二,你曝露年龄了,这几天从您及其他论坛诸位达人的的贴子里面学到很多东西,谢谢。

TOP

返回列表