 
- 帖子
- 531
- 积分
- 1554
- 技术
- 94
- 捐助
- 0
- 注册时间
- 2008-7-17
|
很有见解的分析
顶楼提到的
"再来解释一下为什么echo.有时候会引起错误。文件名中是不能出现:.\的,理论上GetFileAttributes函数都应该返回-1(INVALID_FILE_ATTRIBUTES),然而事实却不是如此,我也不知道这算不算GetFileAttributes函数的BUG:"
首先说明
文件名不能出现:和\ 的
因为这是文件路径中的分隔符
但是句点可以出现的
这个你随便改一个文件名带.就知道了
因为句点原本用作主名和扩展名的分隔符
后来在长文件名LFN设计之时
鉴于句点在文件名中的需求十分迫切
所以微软也做了某种程度的妥协
允许句点出现在文件名之中
但是最后一个句点仍然作为主名和扩展名的分隔符之用
在顶楼的例子中
echo.
实际上就是主名为echo,扩展名为空的文件名的标准写法
所以GetFileAttributes("echo.")的返回值就毫不奇怪了
至于最后提到的“垃圾教程”的问题
我多说几句
楼主站在现在的时空看待这个问题无可厚非
毕竟分析cmd的工作是件挺难熬的事情
能够坚持做下来就已经说明楼主对cmd的热情
顺便对误人子弟的言论发发感慨是很自然的
当然不免有些人躺着也中枪这也是无法避免的
这里仅替这部分前辈做一些解释
我看到的echo.的最早用法来源于NewsGroup的一个讨论组
那是个主要讨论MSDOS和其下的batch的新闻组
伴随着也有一些echo+ echo/ 的用法
但是经过漫长时间的演变
echo.的用法最终成为主流
经过实验证实
MSDOS下echo.确实不会触发文件的匹配搜索
所以至少对于在发现或者发明这个用法前辈来说
在他所处那个的时空和环境中
这个用法是没有任何问题的
至于后来的新人比如我辈不加思索
直接生搬前人可能已经不合时宜的用法
那只能是我辈学习不求甚解的一种表现
而对于那些无责任转发已经失去时效性的教程的传播者而言
也只能感慨人云亦云的惯性真的是太大了
而至于echo.党我也是其中的一员
估计以后还会继续保持下去了
原因无它
相对于它的问题和毛病来说
我的喜好和习惯仍占有绝大的优势 |
|