函数内until语句展开"$@"的疑惑：写法3与写法2是否语义等价？

好问题！咱们一步步拆解这几个写法的逻辑，再对比type2和type3的语义差异。

先理清三个写法的核心逻辑 #

首先明确until的基础语法：until 命令; do 循环体; done，它的逻辑是重复执行循环体，直到until后面的命令执行成功（退出码为0）。

1. Type1为什么失效
   写法：until "echo hi"; do :; done
   这里的"echo hi"是带空格的字符串，shell会把它当作完整命令名去查找，但系统中不存在名为echo hi的命令（命令名不能包含空格），所以每次都会报错command not found（退出码非0），导致循环永远无法终止，自然无法正常打印hi。

2. Type2的执行逻辑
   写法：echo hi; until [ $? -eq 0 ]; do echo hi; done

   • 第一步：先执行一次echo hi；
   • 第二步：检查上一条命令的退出码$?，如果等于0（成功），until的条件成立，循环直接终止；
   • 第三步：如果echo hi失败（退出码非0），进入循环体再次执行echo hi，然后重复检查退出码，直到命令成功。

3. Type3的执行逻辑
   写法：定义函数makesure { until "$@"; do :; done }，调用makesure echo hi

   • "$@"会把传入的参数（这里是echo hi）解析为完整命令执行；
   • until "$@"会先执行目标命令，如果成功（退出码0），循环直接终止；如果失败，执行循环体的空命令: （什么都不做），然后再次执行目标命令，直到成功为止。

type2和type3的语义是否等价？ #

针对你给出的echo hi这个特定场景，两者的执行结果是一致的：都会确保echo hi至少执行一次，失败则重试直到成功。但从通用语义、可靠性和复用性来看，两者并不等价，核心差异如下：

1. 退出码的可靠性不同

• Type2依赖$?变量，这个变量存储的是上一条命令的退出码。如果在第一次执行目标命令和until条件检查之间插入了其他命令（比如sleep 1），$?会被覆盖，导致循环逻辑完全错误。
• Type3直接在until的条件中执行目标命令，每次循环都会直接检查该命令的退出码，完全不受其他操作干扰，逻辑更可靠。

2. 通用性完全不同

• Type2是硬编码特定命令的写法，要复用去执行其他命令（比如curl http://example.com），需要修改多处代码，非常繁琐。
• Type3是通用函数，通过"$@"接收任意命令和参数，调用时只需传入目标命令即可（比如makesure cp file1 file2），复用性极强。

3. 循环体的扩展性不同

• Type2的循环体是重复执行目标命令，如果需要在重试前添加延迟（比如失败后等1秒再重试），需要修改循环体为do sleep 1; echo hi; done，逻辑耦合度高。
• Type3的循环体是空操作，真正的命令执行在until条件环节，要加延迟只需修改循环体为do sleep 1; done，逻辑清晰且不影响目标命令的执行。

总结 #

如果只是针对echo hi这个简单场景，两者的表现一致，但从工程化角度来说，type3的写法更健壮、通用，和type2的语义并不完全等价——type2是依赖上一条命令的退出码来控制循环，而type3是直接绑定目标命令的执行结果来控制循环，后者的逻辑更严谨。

内容的提问来源于stack exchange，提问作者Kevin Dong