一、未启动Shell时，-e参数如何生效？ #

很多人误以为Docker的环境变量依赖Bash这类Shell，但其实环境变量是Linux进程的原生属性——每个进程启动时都会携带一份环境变量表，Docker的-e参数本质是在启动容器的主进程时，直接往这个进程的环境变量表里注入键值对，完全和Shell无关。

举个直观的例子：如果有一个编译好的Go程序（完全不依赖Shell），代码里直接读取环境变量SOME_VAR，用docker run -e SOME_VAR=13 my-go-app启动容器，程序依然能正确读到13，因为Docker在启动这个Go进程时已经把变量写入了它的环境变量表。

哪怕是用busybox这类镜像执行非Shell命令，比如docker run -e SOME_VAR=13 busybox printenv SOME_VAR，这里的printenv是独立二进制程序，它直接读取当前进程的环境变量，也能输出13——全程没有Shell参与解析。

二、为什么实例中返回空行而非预期的123？ #

这种情况大概率是**docker exec执行命令时没有通过Shell解析变量**，导致变量没有被正确展开。常见的踩坑场景有两种：

场景1：宿主机Shell提前解析了变量 #

如果你直接运行：

docker exec my-container ping localhost -c $SOME_VAR

这里的$SOME_VAR会被宿主机的Shell先解析，如果宿主机上没有定义这个变量，就会被替换成空字符串，最终容器内执行的命令变成ping localhost -c ，这显然不符合预期，会输出空行或者报错。

场景2：容器内无Shell，变量无法展开 #

即使你在启动容器时用-e SOME_VAR=123设置了变量，直接用docker exec执行不带Shell的命令，比如：

docker exec my-container ping localhost -c $SOME_VAR

容器内的ping进程是直接启动的，没有Shell帮它解析$SOME_VAR，所以ping会把$SOME_VAR当成字面量参数，这显然不是合法的计数参数，自然会返回空行或错误。

正确的做法 #

要让容器内的变量被正确解析，必须通过Shell来执行命令，把命令用单引号包裹，让容器内的Shell负责变量展开：

docker exec my-container sh -c 'ping localhost -c $SOME_VAR'

此时$SOME_VAR会被容器内的Shell读取并替换成123，ping命令就能正常执行。

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