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.然后使用>>追加文件寫入需要寫入的內容。