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.而后使用>>追加文件写入须要写入的内容。