在K8s Pod中运行bash脚本：两种Command写法的差异与优劣

核心区别 #

这两种写法的本质是sh命令的执行逻辑完全不同：

• Command: []string{"sh", "scripts/start-script.sh"}
  把脚本路径作为sh的直接参数，sh会直接读取脚本文件内容并解释执行。此时脚本顶部的#!/bin/bash这类shebang会被完全忽略，不管脚本写了什么解释器，都强制用当前的sh进程来运行。
• Command: []string{"sh", "-c", "scripts/start-script.sh"}
-c参数是让sh执行后面字符串里的命令。这里相当于在sh会话里手动输入scripts/start-script.sh，系统会先检查脚本的shebang：如果脚本指定了#!/bin/bash，就会调用bash来执行脚本；如果没有shebang，才会用当前的sh执行。

另外参数传递逻辑也有差异：

• 第一种写法中，脚本内的$0会被设为scripts/start-script.sh，Pod定义里Args字段的内容会直接作为脚本的位置参数（$1、$2...）。
• 第二种写法中，$0默认是sh，Pod的Args会被当作sh的参数，不会自动传递给脚本——除非你在-c的字符串里显式处理，比如写成sh -c "scripts/start-script.sh $@"，再把Args放在后面。

功能是否相同？ #

多数简单场景下（比如脚本只用POSIX语法、不需要传参），两种写法看起来效果一致，但本质存在差异：

• 如果脚本依赖bash专属特性（比如数组、[[ ]]条件判断、进程替换），第一种写法用sh执行会直接报错；第二种写法如果脚本有#!/bin/bash，会调用bash执行，就能正常运行。
• 如果需要给脚本传参，两种写法的参数传递逻辑完全不同，第一种更直接，第二种需要额外处理参数。

哪种写法更优？ #

没有绝对的最优解，得看具体场景：

• 若脚本是纯POSIX兼容的，且不需要依赖特定shell，第一种写法更简洁，参数传递也更直接。
• 若脚本依赖bash/zsh等非POSIX特性，或者需要通过shebang指定解释器，第二种写法更可靠，能保证脚本用正确的解释器执行。
• 在K8s镜像中，很多基础镜像的sh是bash的软链接，但也有镜像用dash这类轻量shell（比如Debian系），这时候第一种写法会导致bash脚本运行失败，第二种写法就更稳妥。

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