企业官网建设流程全解析

很多朋友第一次写完 shell 脚本，保存成 demo.sh，然后兴冲冲在终端敲一行demo.sh回车，结果屏幕上直接来一句command not found。于是跑去搜“shell脚本 执行方式”，一搜就出来七八种：bash script.sh、./script.sh、source script.sh、bash -c "..."、管道喂给 bash、sh -c、exec……看完更懵：不都是“执行 shell 脚本”吗，至于搞这么多花样吗？

至于，而且差别还不小。搞懂这几种执行方式，其实不需要背命令，只需要抓住三个关键词：子进程、权限、环境变量。这三样想明白了，以后拿到任何一种执行方式，你自己就能推出它的行为轨迹。

本文就用同一个脚本，把这 5 种最常见的执行方式逐个跑一遍，边跑边验证差异，再用一张表做横向对比，最后讲讲我踩过的几个坑和日常选型习惯。适合刚入门 shell 脚本、正在看“shell脚本基础知识”的同学，也适合写过一阵子脚本但一直没把执行机理弄清楚的兄弟。

1. 先回答那个最常被问的问题：为什么不能直接敲 demo.sh

新手问得最多的不是“有哪几种执行方式”，而是“我明明就在当前目录，为啥敲demo.sh会报 command not found”。这个问题搞明白了，后面一大半概念就通了。

1.1 PATH 和当前目录：一个必踩的 command not found

终端里敲名字执行程序时，shell 不会原地瞎找，而是按照环境变量PATH里定义的目录列表，一个一个目录去找有没有对应的可执行文件。你可以看一下自己机器上的 PATH：

$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

注意，这里面没有当前目录.。这是 Linux/Unix 从很早开始就有的安全设计：如果默认把当前目录加进 PATH，那恶意文件放在你下载目录里，你一敲某个重名命令，可能就执行到了不该执行的东西。所以哪怕脚本就躺在你脚边，你不告诉 shell 它具体在哪，shell 就不会主动找。

想执行当前目录下的脚本，就得明确写出路径，最典型的就是：

$ ./demo.sh

./就是在告诉 shell：“在当前目录下找这个文件”。你也可以用绝对路径，比如/home/you/demo.sh，效果一样。

1.2 可执行位和 shebang：直接跑一个脚本要过两道关

写清楚./demo.sh之后，新手会遇到第二个报错：

$ ./demo.sh -bash: ./demo.sh: Permission denied

这是因为系统在执行一个文件前，会检查它的权限位，特别是“可执行”权限。Linux 上的可执行不是看文件后缀.sh，而是看x权限位。解决办法就是给文件加上执行权限：

$ chmod +x demo.sh

这时候再执行./demo.sh就顺了。但这个“顺”还有一个隐藏前提：文件开头那行#!/bin/bash（也就是 shebang）必须是正确的。当你在终端里执行./demo.sh时，内核看到这个以#!开头的文本文件，就会调用/bin/bash来解释执行它。

所以./demo.sh这种方式，对文件有两个硬性要求：

• 文件要有x可执行权限；
• 文件开头的 shebang 要么存在且指向正确的解释器，要么系统能用默认方式兜底。

这两个条件任何一个出问题，都会直接卡壳。后面第 5 章我会专门讲 Windows 下编辑脚本导致的 shebang 坑，这里先点到为止。

1.3 执行方式背后的分水岭：子进程与当前进程

初学者最容易忽略的一个概念是：执行脚本时，究竟是“原来的 shell 进程去跑脚本”，还是“新开一个子进程去跑脚本”？

绝大多数执行方式是前者——新起一个子进程。脚本里定义的变量、函数、cd 目录变化，只存在于子进程里，脚本跑完子进程退出，一切归零，不会污染你当前的终端环境。

只有少数方式（比如 source）是“当前 shell 进程直接去读脚本内容执行”。这种情况下，脚本里设置的环境变量会留在你的终端里，脚本里cd会真的切换你当前目录，脚本里写exit会真的把你的终端干退出。

这两种模型，就是整个“执行方式”问题的核心。下面进入实操环节。

2. 五种执行方式逐个跑一遍：同样的脚本，不同的结果

为了让你看得更直观，我先准备一个脚本，里面故意放上 PID 打印、目录切换、环境变量导出、时间戳转换和 for 循环，方便后面观察五种方式的差别：

#!/bin/bash # exec_demo.sh 用于演示不同执行方式的差异 echo "脚本内 PID：$$" echo "脚本名 argv0：$0" echo "启动目录：$(pwd)" TS=$(date +%Y%m%d%H%M%S) echo "当前时间戳：$TS" cd /tmp export DEMO_ENV="script-set-value" for i in 1 2 3; do echo "for 循环第 $i 次，PID=$$" done echo "脚本执行完毕"

这个脚本里用到了date +%Y%m%d%H%M%S把当前日期时间转成数字串，这是日常写日志文件名特别常用的套路；for循环则是 shell 脚本基础里最常碰到的结构。接下来五种方式，全都用它测试。

2.1 方式一：bash demo.sh——用指定解释器临时跑一次

命令长这样：

$ bash exec_demo.sh

这种方式的本质是：你把脚本文件路径当作参数传给 bash 这个程序，由 bash 自己去读取并解释文件内容。好处非常明显：

• 不需要可执行权限，只要能读文件就行；
• 不依赖文件首行的 shebang，哪怕文件第一行是空的，或者根本没有人写过#!/bin/bash，你也能跑；
• 行为稳定，指定了解释器就按它的语法走，不受“默认 shell 是谁”的影响。

实测输出大致是：

$ bash exec_demo.sh 脚本内 PID：27321 脚本名 argv0：exec_demo.sh 启动目录：/home/user 当前时间戳：20250108153012 for 循环第 1 次，PID=27321 for 循环第 2 次，PID=27321 for 循环第 3 次，PID=27321 脚本执行完毕

注意 PID 是 27321，这和你终端 shell 的 PID 大概率不是同一个。脚本在里面怎么折腾目录、怎么 export 变量，跑完就结束了，你的终端环境一点不受影响。

如果你想在 Ubuntu 上临时跑个脚本，又不想管权限问题，bash script.sh是最省心的选择。但提醒一句：sh script.sh和bash script.sh不是一回事，在 Debian/Ubuntu 系列上/bin/sh通常指向 dash，语法能力比 bash 弱（比如不支持数组、source这种写法），脚本一旦用了 bash 特有语法，sh跑就会报错。

2.2 方式二：./demo.sh——最接近“运行程序”的体验

先给脚本加执行权限，然后：

$ chmod +x exec_demo.sh $ ./exec_demo.sh

输出大体一样，但有一个细节值得留心：脚本里的$0会显示成./exec_demo.sh而不是exec_demo.sh。$0就是脚本被调用时的 argv0，这个值在实际工程里很有用，因为你可以靠它反推出脚本所在的目录：

DIR=$(cd "$(dirname "$0")" && pwd)

这样不管脚本从哪个目录被调用，都能找到自己“老家”的位置，后面引用同目录的配置文件、模板文件就不会跑偏。这是写正式脚本时非常重要的一招。

./demo.sh这种方式，本质上依赖于内核解析 shebang 并拉起解释器。它的优点是：

• 执行机制和运行一个系统命令一致，最符合“命令”的直觉；
• 用户不需要关心解释器到底叫 bash 还是 zsh，脚本自己指定；
• 脚本可直接放进/usr/local/bin后，在任意位置敲名字执行。

缺点是门槛高：权限没加不行，shebang 错了不行。而且如果换目录执行，./的路径写法也可能导致找不到文件。

如果文件没有 shebang，但你又给了它可执行权限，执行时系统会返回 ENOEXEC，bash 会尝试用当前 shell 去解释这个文本文件。不同 shell 行为不完全一致，所以正式脚本一定别省 shebang 这一行。

2.3 方式三：source demo.sh——在当前 Shell 里加载执行

命令写法有两种，完全等价：

$ source exec_demo.sh # 或者 $ . exec_demo.sh

.是 POSIX 标准写法，source是 bash 的扩展。执行之后再看输出，你会发现一个非常关键的差异——PID 和你的当前 shell 完全相同：

$ source exec_demo.sh 脚本内 PID：27012 脚本名 argv0：bash 启动目录：/home/user ...

如果你在执行前先看下当前 shell PID：

$ echo $$ 27012

发现一模一样。这就是 source 的本质：它不是一个新开进程去跑脚本，而是把脚本内容一行一行读进来，像是你直接在终端里敲了这些命令一样。

好处也在这里：脚本里export DEMO_ENV="script-set-value"执行完之后，这个变量会残留在你当前终端里：

$ echo $DEMO_ENV script-set-value

同时，脚本里的cd /tmp也让你的当前目录真的变成了 /tmp：

$ pwd /tmp

这种“加载式”执行，最典型的应用就是加载配置和公共函数库。比如每次安装完新软件，你大概率执行过source ~/.bashrc或. /etc/profile，本质就是把配置文件里的环境变量、alias 加载到当前 shell 里来。

但 source 是一把双刃剑：脚本里如果有exit 3，你不是退出一个子进程，而是直接把这个终端会话给关了。我在第 5 章会专门讲这个坑。

2.4 方式四：bash -c "..."——把脚本内容当字符串传给解释器

前面三种方式的核心对象都是“文件”，但 bash 其实可以直接执行一个字符串参数：

$ bash -c 'echo "当前身份是 $0"; echo "PID 是 $$"; echo "时间戳是 $(date +%Y%m%d%H%M%S)"'

实测输出：

当前身份是 bash PID 是 27534 时间戳是 20250108153012

这里的重点是引号到底用单还是双。如果你用双引号：

$ bash -c "echo $(date)"

你会发现这个$(date)是在当前 shell 先被展开，然后把结果字符串传给 bash -c 去执行。有时候这会造成“到底谁在执行这条命令”的困惑。想确保里面的变量、命令替换都在新的 bash 子进程里解析，就尽量用单引号把整段命令包起来。

这种方式在日常工作中太常用了。最常见的场景是：

• 远程执行：ssh user@host "bash -c 'echo hi'"；
• 在管道、cron 里临时拼一段动态命令；
• 想在一个干净的 bash 环境里跑一段代码，避免当前 shell 环境干扰。

如果你只是想把一个脚本文件跑起来，一般不用绕这一层，直接在bash -c里再调用脚本文件即可：

$ bash -c './exec_demo.sh'

本质上和直接./exec_demo.sh行为一致，但多包了一层 bash 子解释器。

2.5 方式五：cat demo.sh | bash——从标准输入执行

最后一种更“野”的方式，是把脚本内容通过标准输入喂给 bash：

$ cat exec_demo.sh | bash

或者用输入重定向：

$ bash < exec_demo.sh

两者效果基本一样，bash 会从 stdin 读取命令来执行。它同样不需要可执行权限，也不需要 shebang 有多正确，因为解释器你自己指定了。

这种方式最大的价值在于：脚本甚至可以不存在于本地磁盘上。比如我们常看到的：

$ curl -sL https://example.com/install.sh | bash

还有一个日常调试非常好用的兄弟命令，配合 heredoc 使用：

$ bash -s <<'EOF' echo "heredoc 里的命令" TS=$(date +%Y%m%d%H%M%S) echo "时间戳: $TS" EOF

bash -s表示“从标准输入读脚本”，后面的参数会作为脚本的位置参数传进去。heredoc 里的'EOF'加了单引号，能确保$TS这些变量在当前 shell 阶段不做展开，完整交给 bash 子进程解析。这种写法在快速验证一段逻辑、或者写自动化流水线的时候，非常顺手。

3. 一张表看懂差异：进程、权限、环境变量如何联动

五种方式都跑完，信息量有点大，我用一张表把核心差异收敛起来。这张表建议你直接存下来，比死记硬背命令有用得多。

3.1 核心差异对照表

这里要补充一个容易混淆的点：表格中bash -c "……"那一行的特性，指的是“直接执行字符串”的情况；如果你在字符串里再调用./exec_demo.sh，那被调用的脚本仍然按照自己的方式去执行。所以判断执行方式时，要看“最终那一步脚本内容是怎么被解释的”。

3.2 从 PID、退出码和环境变量验证差异

理论说一千遍，不如亲手验证一遍。我常用的验证组合有三个。

第一，看 PID。脚本里打印$$，终端里也打印$$，然后分别用bash demo.sh和source demo.sh执行，差异一目了然。

第二，看退出码。先造一个退出脚本：

cat > exit_demo.sh <<'EOF' echo "我要退出啦" exit 3 EOF

然后用bash exit_demo.sh，脚本跑完，你的终端还活着，而且能拿到退出码：

$ bash exit_demo.sh 我要退出啦 $ echo $? 3

如果用source exit_demo.sh，那就是当场把终端送走，建议你放在子 shell 里安全测试：

$ ( source exit_demo.sh ) 我要退出啦 $ echo $? 3

括号( ... )会新起一个子 shell，在子 shell 里 source 脚本，退出码被外面捕获，当前终端毫发无损。这个技巧本身也很实用。

第三，看环境变量。脚本里export DEMO_ENV="script-set-value"，用bash exec_demo.sh跑完之后：

$ echo $DEMO_ENV （空）

用source exec_demo.sh跑完之后：

$ echo $DEMO_ENV script-set-value

这个现象后面隐藏的规则是：环境变量的传递方向是父进程传给子进程，子进程里怎么改都传不回父进程。子进程拿到的是父进程环境的“复印件”，在复印件上涂抹，原件不会有任何变化。source 的本质不是复印件，是直接拿原件书写，所以改动留了下来。

3.3 环境变量“穿透”和“隔离”的实际影响

理解了“复印件”和“原件”的区别，很多烦心事就能提前避开。

比如你写了一个部署脚本，里面export JAVA_HOME=/opt/jdk17。如果你用它bash deploy.sh，跑完你在终端里敲java -version，用的还是原来的版本。这不是脚本没生效，是它生效在了一个和你终端无关的子进程里。

反过来，如果你用source deploy.sh，那脚本里cd、export、unset、alias、umask全部会“穿透”到你当前环境，改目录、改变量、改默认权限掩码。有时候这正是你想要的，比如配置开发环境；但有时候你会被自己坑到——脚本里一个无意的cd，就能让你的下一个操作在完全不同的目录里执行。

我这里的原则很简单：要隔离，就 bash；要穿透，就 source。拿不准的时候，默认用 bash。

4. 实战选型：哪种方式对应哪种场景

讲完原理，聊点实在的：日常写脚本、调试脚本、部署脚本，到底该用哪种？

4.1 日常验证和临时测试首选 bash

如果你正在起草一个脚本，或者需要快速验证一段逻辑能不能跑通，bash script.sh是我的默认选择。原因就俩字：省事。不需要chmod，不需要管 shebang，写错了直接改，改了再跑，没有任何额外负担。

哪怕是正式脚本，在没有确定最终交付形态之前，用 bash 执行来调试也完全没有问题。开发期和生产期可以分开，开发期用 bash 脚本路径，交付期再配好 shebang 和权限。

4.2 加载配置和复用函数必须 source

凡是“影响当前环境”的需求，就要毫不犹豫地 source。场景很具体：

• 加载/etc/profile、~/.bashrc、~/.profile，让环境变量立即生效；
• 加载公共函数库，比如source /opt/lib/common.sh，然后直接调用里面定义的函数；
• 初始化当前 shell 的开发环境，比如设置 Python 虚拟环境、切 Node 版本、加载 SDK 路径。

这个场景下，如果误用了bash config.sh，那所有变量和函数都只活在那个短暂子进程里，等脚本退出一看，一切照旧，白跑。这也是为什么很多人第一次写环境初始化脚本，总觉得“没生效”，多半就是执行方式选错了。

4.3 作为系统命令分发用 ./ + shebang

当脚本要正式交付给其他人使用，或者自己打算把它放进~/bin、/usr/local/bin全局使用，这时候就不要再用bash script.sh了，而是走标准流程：

chmod +x myscript.sh sudo cp myscript.sh /usr/local/bin/myscript

之后在任意目录直接敲myscript就能运行。这里的./script.sh只用于测试，真正让它“命令化”的关键是：可执行权限、shebang、以及把它放到 PATH 能找到的目录里。脚本首行#!/usr/bin/env bash比#!/bin/bash更通用，因为它会去 PATH 里找 bash，在 macOS 这类环境上容错性更好，但前提是 PATH 里确实有 bash。这点在 cron 这类最小环境里要小心，所以 cron 里我反而更喜欢写绝对路径。

4.4 远程、管道和自动化场景用 bash -c / stdin

写自动化时，你经常没有权限或者没有意愿在目标机器上保存一个脚本文件。这时候bash -c和 stdin 方式的优势就体现出来了：

$ ssh user@host "cd /var/log && grep 'ERROR' app.log | tail -20"

这就是一个典型的“远程 + 字符串执行”。想传更复杂的多行脚本给远程机器，可以利用 stdin 方式：

$ ssh user@host 'bash -s' < local_script.sh

本地文件 local_script.sh 的内容会被远程 bash 从 stdin 读取执行，本地脚本还能拿到远程机器上相对路径的环境。这种方法我在批量运维时经常用，省去先上传再执行、执行完再清理的工作量。

4.5 特殊方式 exec 和后台执行

严格说exec demo.sh不算这 5 种主流的并列项，但它值得单独了解，因为很多新手会把exec和bash搞混。

exec是非常特殊的执行：它会用一个新的程序替换掉当前进程，不额外创建子进程，进程 PID 不变。你在终端里敲exec bash，终端直接变成一个新的 bash 会话；你在脚本最后写exec ./deploy.sh，则是让当前脚本进程被 deploy.sh 顶替掉。这种行为在容器启动脚本、登录脚本里很常见，设计意图是“进程不退出，使命交接”。和 source 最大的区别是：source 是当前 shell 继续跑，exec 是当前 shell 彻底换人。

后台执行则是另一个维度的问题，和“用什么解释器”正交：

$ nohup ./start.sh > run.log 2>&1 &

nohup让脚本在终端关闭之后还能继续跑，&放到后台，> run.log 2>&1把输出落盘。注意这里我仍然用的是./start.sh，说明后台执行不改变执行方式的进程模型，它只是“放到后台调度”而已。

5. 最容易翻车的几个细节，每条都是真金白银的教训

这章写的是我实际踩过、或者看别人踩过最多的坑。每一条都很碎，但碎坑最致命。

5.1 source 一个含 exit 的脚本：终端直接没了

这个坑我提过好几次，因为它是五级地震级别的体验。有次我在一台服务器上写环境初始化脚本，脚本中间有一行exit 1用来做错误中断。我用source init_env.sh跑，想让环境变量留在终端里。结果脚本执行到exit 1，整个 SSH 会话立刻断开，连接中断，我一脸懵地坐在本地终端前。

原因非常直接：source 是在当前 shell 里执行，脚本里的exit就等同于当前 shell 自己退出。一个普通子进程跑exit，只是子进程退出，父 shell 毫发无损；但 source 没有“子进程”这层护城河。

正确做法是：如果需要加载环境变量，同时还要处理错误退出，脚本内部不要直接写exit，而是返回退出码，让调用方决定怎么办：

# 写法一：脚本里用 return，source 后不会退出当前终端 if [ ! -f "config.sh" ]; then echo "配置文件不存在" return 1 fi # 写法二：调用方放在子 shell 里测试，避免被清场 ( source exit_demo.sh )

5.2 脚本里的 cd：执行方式不同，目录走向天差地别

脚本里带cd是很常见的事，但这个cd的影响范围完全取决于你怎么执行它。我用前面的 exec_demo.sh 演示过：

• bash exec_demo.sh跑完，当前终端目录不变，因为 cd 发生在子进程里；
• source exec_demo.sh跑完，当前终端目录变成 /tmp，因为每一条命令都在当前 shell 里生效。

切换到子目录去操作还好说，要是脚本里写了cd /或者cd ~，source 完之后你都不知道自己现在身在何处。所以我写脚本时有个习惯：无论脚本预期用哪种方式执行，凡是会改变目录的操作，尽量放在子 shell 里执行，防止意外污染调用方环境。

# 在子 shell 中切换到目标目录执行，不影响当前目录 ( cd /target/dir || exit 1 ./do_something.sh )

5.3 Windows 下编辑脚本导致的 CRLF/BOM 问题

这个坑很多人第一次遇到时完全摸不着头脑。在 Windows 上拿记事本或某些编辑器写脚本，保存后传到 Linux 执行，文件里每行末尾都会带着一个\r（回车符）。你执行./demo.sh时，内核去读 shebang 那一行，看到的不是#!/bin/bash而是#!/bin/bash\r，于是报错说解释器不存在：

-bash: ./demo.sh: /bin/bash^M: bad interpreter: No such file or directory

^M就是那个\r的显示形态。排查方法是用file命令看文件类型：

$ file demo.sh demo.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators

看到with CRLF line terminators就说明是 Windows 风格换行了。处理方式很无脑但有效：

$ sed -i 's/\r$//' demo.sh

跑完再file一下，如果不再显示 CRLF，就正常了。防止这个问题的根源办法：编辑器统一开“保存为 Unix 换行”的选项，别让你的脚本文件在 Windows 和 Linux 之间反复横跳。

另外还有一个少见但更隐蔽的问题：如果文件开头带了 BOM（Unicode 字节序标记），内核同样解析不了 shebang。所以脚本文件务必用纯 UTF-8 无 BOM 保存，别让编辑器画蛇添足。

5.4 cron、nohup 里执行脚本的注意事项

定时任务和后台任务里执行脚本，常见翻车点都是环境变量。cron 默认的 PATH 通常只有/usr/bin:/bin这种最小集，而你在交互终端里正常使用的那些目录、函数、alias，cron 一概不认。

所以 crontab 里写命令时，我的习惯是：

• 脚本内部显式写#!/bin/bash，不给系统猜的机会；
• crontab 里写绝对路径，不要写./demo.sh；
• 如果脚本依赖自定义环境变量，在脚本开头显式 export，或者 source 对应的环境配置文件；
• 输出重定向到日志文件，比如>> /var/log/myscript.log 2>&1，不然出问题连报错都看不到。

nohup 后台跑也有类似情况。以前我用nohup ./start.sh &开启服务，然后关掉 SSH，以为万事大吉，结果发现服务一分钟后就退出了。原因往往不是 nohup 没用，而是脚本里的某个命令依赖了当前 shell 的某个环境变量，终端一关，环境没了，命令失败。

正确姿势是把环境变量和启动逻辑都写进脚本里，让脚本自包含，然后再 nohup 执行：

$ nohup /opt/app/start.sh > /opt/app/run.log 2>&1 &

5.5 我个人的习惯：一个极少写进文档的实用组合

压轴分享一个我常用的纯个人习惯组合：用 heredoc + bash -s 做快速稿，代替一次一次创建临时文件。

比如我需要临时拼一段逻辑，不想为了十行代码专门建一个 .sh 文件，也不想去按上下箭头找回写过的历史，就写：

$ bash -s <<'EOF' TS=$(date +%Y%m%d%H%M%S) DIR="/tmp/logs" mkdir -p "$DIR" echo "当前时间戳: $TS" echo "日志目录: $DIR" for file in "$DIR"/*.log; do [ -e "$file" ] && echo "处理 $file" done EOF

每次敲完，bash 子进程干净执行，环境不残留，调试迭代很快。等逻辑确认为正式脚本，再把它抽成一个带 shebang、带权限、带参数校验的真正文件。

还有一个调用技巧：想让 heredoc 里的变量在当前 shell 先展开一部分，另一部分留给 bash 子进程解析，可以在 heredoc 标记里做文章。<<'EOF'是全部不做展开，<<EOF是全部先让当前 shell 展开一次。一定要想清楚自己到底要哪一边，这个细节很微妙，但用对了能省很多转义功夫。

说实话，执行方式这件事，折腾明白之后回头看，真的没什么高深内容。它不像算法题需要智商，更像是一张地图：知道了哪个方式对应哪条路，前面有什么陷阱，剩下就是肌肉记忆了。希望这篇把“子进程、权限、环境变量”讲透的文章，能帮你少走几次我当年走过的弯路。