Windows batch,echo到文件不成功,只打印出ECHO is on.

jenkins 执行Windows batch command的时候,如果想要读写文件,echo到文件不成功.

bat 代码如下:

set ctime=%date%_%time%
echo %ctime%>test.txt
echo %FOLDERNAME%>test.txt
echo "finished!"

 

执行完毕,打开文件只有一句:

 

修改bat代码:

1 set ctime=%date%_%time%
2 echo %ctime%>test.txt
3 echo %FOLDERNAME%>test.txt
4 echo "finished!">test.txt

 

打开文件发现finished写入文件成功了。

 

初步怀疑是bat写入文件只对字符串有效, 对变量失效了。但是仔细一想,这段代码是逐步执行,不会出现变量延迟的情况。于是,把> 改写成>> 。

这样的话代表追加到文件,而不是写入。

1 set ctime=%date%_%time%
2 echo %ctime%>>test.txt
3 echo %FOLDERNAME%>>test.txt
4 echo "finished!">>test.txt

执行两次,结果如下:

由此可见,并非是变量和string有所不同,而是echo变量到文件后,ECHO is on被写入了文件,从而冲掉了之前的echo。

那ECHO is on 又是从哪里来的呢?

 原来代码里的

echo %FOLDERNAME%>>test.txt

会因为%FOLDERNAME%未定义,打印出来ECHO is on.

为何会如此呢?

因为bat里的有一个命令:echo 执行的结果就是ECHO is on, 当%FOLDERNAME% 未定义的时候,bat会自动将这行代码解析成:

echo >>test.txt

稍微有点儿诡异,不报错,而是直接用忽略变量,执行echo的结果写入test.txt文本文件。这里有两点:

1. 变量未定义,则该行命令,直接忽略该变量,可能就完全成为了另外一个动作了。如果碰巧该命令能够顺利执行,那么将不会报错。

这是一个很容易捡漏的地方,如果按照正常逻辑读代码,完全正确的脚本,可能会因为没有正确赋值,成为另外一个完全不同的脚本。(安全隐患。。。。)

2. >>写入文件的动作,是将>>前面的执行结果写入。简单点而说,如果是fn(s) >>test.txt。 那么写入动作,是会等待fn执行完毕写入return返回值的。虽然bat没有函数这一个概念。

至于以后写bat处理写入文件:

1.首先清空文件:

cd .>test.txt

2.然后使用>>追加文件写入需要写入的内容。

posted @ 2015-05-04 13:23  小侠女  阅读(2621)  评论(0编辑  收藏