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.而後使用>>追加文件寫入須要寫入的內容。