昨天晚上金锰跑过来和我说snap命令在某台机器上不能正常运行.
我过去看了下,只要键入"snap"然后回车,CMD就提示"/Windows is not expected.".
打开snap.bat文件,使用echo命令来定位,最后将问题锁定在这段代码上:
@rem ensure snap/bin is first on the path so that updated tools run from there
for /f "delims=; tokens=1" %%i in ("%path%") do (
if NOT "%%i" == "PATH=%~dp0%" (
set PATH=%~dp0;%path%
)
)
出错的代码就是set PATH=%~dp0;%path%这句.仔细查看了该电脑的环境变量path,结果发现其中有:
path=...;C:/Program Files (x86)/Windows SDK/";...
因为括弧在CMD中是特殊字符(用来框住代码块),所以这句set命令失败并打印出之前的错误信息.
罪魁祸首是因为开发员错将Vista 64位安装在这台机器上,所以其他机器能正常运行而它不行,也就是所谓的人品问题.
之前在AMD 64上的机器跑UT的时候也遇到失败的情况,原因也是源自路径问题.这使我想到了现在很多软件,包括正在开发的,它们的假设还是基于32位系统的.所以软件测试的时候,不知道测试人员是不是考虑到对这些显式的和隐式的假设条件进行测试.
我过去看了下,只要键入"snap"然后回车,CMD就提示"/Windows is not expected.".
打开snap.bat文件,使用echo命令来定位,最后将问题锁定在这段代码上:
@rem ensure snap/bin is first on the path so that updated tools run from there
for /f "delims=; tokens=1" %%i in ("%path%") do (
if NOT "%%i" == "PATH=%~dp0%" (
set PATH=%~dp0;%path%
)
)
出错的代码就是set PATH=%~dp0;%path%这句.仔细查看了该电脑的环境变量path,结果发现其中有:
path=...;C:/Program Files (x86)/Windows SDK/";...
因为括弧在CMD中是特殊字符(用来框住代码块),所以这句set命令失败并打印出之前的错误信息.
罪魁祸首是因为开发员错将Vista 64位安装在这台机器上,所以其他机器能正常运行而它不行,也就是所谓的人品问题.
之前在AMD 64上的机器跑UT的时候也遇到失败的情况,原因也是源自路径问题.这使我想到了现在很多软件,包括正在开发的,它们的假设还是基于32位系统的.所以软件测试的时候,不知道测试人员是不是考虑到对这些显式的和隐式的假设条件进行测试.