本帖最后由 likeyou32 于 2024-3-15 15:59 编辑
- @echo off
- set tt=woshi
- call :nihao %tt% ss
- echo %tt% %ss% zheli %p%
- goto:eof
- echo 33333333333333333333333333
- :nihao
- set p=%1hundan
- set %2=333
- goto:eof
复制代码 再来解说这段代码,这段代码与一楼的代码几乎完全一致,只是第3行call :nihao后第一个参数tt变成了%tt%,其余与一楼完全一样,只解说这点不一样的:
第8行:p=%1hundan,%1代表%tt%,%tt%就是第2行赋值的woshi,所以p就被赋值为woshihundan。其余输出与一楼一样。
总结:call :nihao后的参数,如果是百分号或感叹号引出的变量,那么前边的代码应该有赋值,可仔细往前找找;如果没有百分号或感叹号,则应是一个新变量,应该会在call转到后的批处理中进行赋值。- @echo off
- set tt=woshi
- call :nihao %tt% ss
- echo %tt% %ss% zheli %p%
- goto:eof
- echo 33333333333333333333333333
- :nihao
- set p=%1hundan
- set %2=333
- set %1=444
- goto:eof
复制代码 还可以做这个测试,这里第3行参数是%tt%,第10行,将444赋值给%1的时候,你会发现根本不起作用,变量tt仍旧是第2行赋值的woshi,还可以将第10行改为set %tt%=444,你会发现仍不起作用,tt最后输出的还是woshi,只有将第10行改为set tt=444,这样才会起作用,最后echo %tt%输出444。结论,set 赋值的时候,=号左边的变量绝对不能带%%号或感叹号,即set %tt%=444是错误的,tt不会改变,只有set tt=444这样才对,tt才能被赋值。 好像也不对,应该是变量tt从未被赋值的时候,可以用set %tt%=444这样进行赋值,假如tt已经有赋值了,就必须用set tt=444进行赋值。好像又不对,我从新打开一个cmd窗口,测试set %tt%=444发现会提示命令语法不正确,,可我刚刚明明测试没问题啊,,啊,,我要发疯了,难道是变量延迟惹的祸 ?难道cmd窗口未关闭,临时变量值依旧会存在?可为什么不报错啊,邪门了!往后再进行测试,必须重新打开cmd窗口,甚至换一台电脑,nnd,明明测试的好好的,测试了好多次都没问题,,突然一转眼不经意间报错了,辛辛苦苦测试的全白费了。唉,令人着恼的cmd啊! |