直接说结论：Shell这东西，你天天在用，但“进入Shell”这件事，很多人其实没真正想明白。我经常在群里看到有人问“怎么进入Shell”“Shell和终端是不是一回事”，还有人以为写脚本才叫Shell，命令行就是终端。今天我打算把这件事拆开讲透。我理解的“两种进入Shell方式”，一种是你打开终端、敲命令、等回显，这种叫人机对话；另一种是写一个脚本文件，丢给Shell去批量执行，这种叫自动化。前者是交互式Shell，后者是脚本式Shell。搞懂这两种方式的区别，你才能真正理解终端上那些看似“玄学”的行为：为什么有时候别名不生效、为什么脚本里cd不改变当前目录、为什么source和./执行结果不一样。这篇文章我就围绕这两种方式，把它们的原理、实操场景、常见坑一次讲清楚，适合刚接触Linux命令行的人，也适合写了段时间脚本但没系统梳理过的人。
1. 先搞清楚：所谓“进入Shell”到底在说什么
1.1 Shell是什么，为什么一上来就要分两种方式
Shell的字面意思是“壳”，包在操作系统内核外面的一层程序。它的核心工作只有一个：读入你给的命令，解析成系统能理解的动作，然后执行，再把结果返回给你。换句话说，Shell是人和内核之间的翻译官。
但问题在于，这个翻译官有两种工作模式。
一种是你一句、它一句，像聊天一样。你输入ls，它列出文件；你输入cd /tmp，它就切目录；你输入错了，它立刻报错。这种模式叫交互式Shell，英文叫interactive shell。大多数人在终端里敲命令，用的就是这种模式。
另一种模式是你把一堆命令提前写进一个文件，然后把这个文件整个交给Shell去跑，跑的过程里不需要你实时输入任何东西。这种模式叫脚本式Shell，也就是我们常说的Shell脚本。脚本文件本质上是命令的有序集合，Shell按顺序逐行解释执行。
很多教材会把“Shell”等同于“命令行工具”，把“Shell脚本”单独拿出来讲，导致新手总觉得这是两个东西。其实不对，它们是同一个解释器的两种用法，底层机制完全一样，区别只在“交互”和“批处理”这两个词上。理解这一点，是后面所有内容的地基。
1.2 两种方式的一张对比表
我先把两种方式的关键差异列出来，后面每个点再展开讲。
| 对比项 | 交互式Shell | 脚本式Shell |
|---|---|---|
| 输入来源 | 键盘（通常是终端） | 脚本文件 |
| 是否有提示符 | 有（如$、#） | 无 |
| 是否有人参与 | 人在实时输入 | 无人值守，批量执行 |
| 典型场景 | 临时查文件、调试命令、日常运维 | 定时任务、部署脚本、批量处理 |
| 环境加载 | 登录Shell会加载profile文件 | 默认加载较少，取决于调用方式 |
| 别名（alias） | 默认可用 | 默认不可用 |
| 作业控制（Ctrl+C等） | 可用 | 通常不适用 |
| 出错处理 | 报错后继续等人输入 | 默认报错后继续跑下一条，需要主动设置 |
这张表不是死规矩，不同发行版、不同Shell（bash、zsh、sh）会有细微差别，但整体框架就是这样。我建议你先记住一个核心结论：交互式Shell是为“人”设计的，脚本式Shell是为“机器批量执行”设计的。
2. 方式一：交互式Shell——人机对话的终端
2.1 你每天打开终端，其实已经进入了交互式Shell
先别把“进入Shell”想得多神秘。你按下开机键登录系统，打开一个终端窗口（比如GNOME Terminal、Konsole、iTerm2），看到类似user@host:~$的提示符，这时候你其实已经“进入”了一个交互式Shell。
很多人会把终端和Shell混为一谈。终端（Terminal）只是一个窗口程序，负责显示字符、接收键盘输入；Shell才是真正解释命令的程序。终端好比是电话机，Shell好比是电话线那头的人。你对着电话机说话，实际上是在和人交流。
在这个交互式Shell里，你可以做几件很自然的事：查看文件、切换目录、启动程序、配置环境变量、调试单条命令。我个人的习惯是，凡是需要“看一步走一步”的操作，比如排查网络问题、分析日志、测试某个命令的参数，我都先在交互式Shell里手动跑一遍，确认无误后再考虑要不要写成脚本。
交互式Shell有个特点：它默认会加载一套用户环境配置。bash会依次读取/etc/profile、~/.bash_profile、~/.bashrc等文件，把预设的PATH、别名、函数、提示符样式全部准备好。这也是为什么你刚打开终端就能用ll（如果配置了别名）而新开的脚本里却不行。
2.2 登录Shell与非登录Shell：同一台机器，两个不同的“出场配置”
讲到交互式Shell，绕不开一个概念：登录Shell（login shell）和非登录Shell（non-login shell）。这俩词看着抽象，但你大概率每天都在切换。
登录Shell，指的是你通过登录流程（比如输入用户名密码、SSH远程连接）获得的第一个Shell。它的特点是会读取系统的用户环境配置文件，把这些配置文件里设置的环境变量、启动脚本都执行一遍。通俗地说，这是“全新接待”模式，把家里的所有家当都摆出来。
非登录Shell，指的是你已经登录系统后，再启动的新的Shell。比如你在终端里敲一个bash命令，或者开一个新的终端标签页（在某些情况下），得到的就是非登录Shell。它通常只读取~/.bashrc，不会重复加载那些登录配置。
这里有一个很经典的坑：你通过SSH登录时是登录Shell，配置了某个环境变量，一切正常。但你在脚本里或者通过定时任务执行命令时，发现那个环境变量不存在了。原因往往是定时任务使用的是非登录Shell，加载的配置文件不一样。解决思路也简单：要么在脚本开头显式source需要的配置文件，要么把变量写到/etc/environment这种全局文件里。
我建议你把“登录Shell加载登录配置、非登录Shell只加载基础配置”这个逻辑记牢，遇到“明明配置了却不生效”的问题，先想想当前到底处于哪种Shell。
2.3 交互式Shell的几个实用技巧
交互式Shell既然是为“人”设计的，自然有一些方便人的机制。我挑三个最常用的说。
第一是提示符（prompt）。bash的默认提示符由PS1变量控制，常见内容是用户名、主机名、当前目录。很多人觉得提示符无所谓，其实它是个重要信息源。我习惯把当前Git分支、Python虚拟环境名都塞进提示符里，这样在多个项目间切换时不容易迷路。你也可以自己改：export PS1='[\u@\h \W]\$ '，立刻生效，刷新终端就恢复默认。
第二是历史记录。交互式Shell会把你敲过的命令存起来，默认存在~/.bash_history里。方向键上下翻历史是最基本的操作，但更高效的是Ctrl+R反向搜索：输入几个关键字就能调出以前敲过的长命令。我几乎每天都要用这个功能，特别是那种参数特别多的命令，不想再手敲一遍。
第三是别名（alias）。alias ll='ls -alF'这类设置，本质上就是用短名字代替长命令。但你要记住一个关键限制：别名默认只在交互式Shell里生效，脚本里不生效。这也是为什么你在终端里能用ll，写进脚本却报“command not found”。原因不是没配置，而是bash在解析脚本时不会展开别名。
2.4 我在什么情况下会优先选择交互式Shell
结合实战经验，我总结几种适合用交互式Shell的场景：临时查询系统状态（比如free -h看看内存）、调试单条命令参数、验证某个配置文件是否生效、快速计算、测试正则表达式。这些都是“一次性”操作，没有必要写脚本。
还有一个反直觉的用法：排查脚本问题时，我反而会先回到交互式Shell。比如脚本里某个命令执行失败，我会把这一行命令单独复制出来，在终端里手动跑一遍，看它到底报什么错、输出是什么格式、参数是否带对了引号。这一步叫“最小化复现”，比在脚本里加一堆echo调试快得多。
交互式Shell的缺点是显而易见的：不能复用、不能自动化、依赖人盯着。你不可能每天凌晨3点爬起来手动敲一遍备份命令，这时候就需要第二种方式上场了。
3. 方式二：脚本式Shell——把命令写进文件批量执行
3.1 一个最简单脚本的完整生命周期
先看一个最基础的例子。假设我们要写一个脚本，打印当前时间，并列出当前目录的文件。
#!/bin/bash # 这是一个最简单的脚本 echo "当前时间: $(date)" ls -l这个脚本有三行，第一行#!/bin/bash叫做“shebang”，它告诉系统用哪个解释器来执行这个脚本。第二行是注释。第三行、第四行是要执行的命令。
要让这个脚本跑起来，标准流程是：
- 用文本编辑器把上面内容保存成
test.sh。 - 给它加上可执行权限：
chmod +x test.sh。 - 运行它：
./test.sh。
很多人卡在第3步，直接敲test.sh会报“command not found”。原因在于当前目录.通常不在PATH环境变量里，系统找不到这个命令。你在前面加./，明确告诉Shell“就在当前目录找这个文件”，它才能执行。这个细节等下还会在常见问题里细说。
执行的过程是这样的：Shell读取文件第一行，发现#!/bin/bash，于是启动一个bash子进程，让这个子进程逐行读取并解释文件后面的内容。每一行命令的执行权限、环境变量，都和你在交互式Shell里敲一样的效果。
3.2 shebang、执行权限、PATH：脚本能不能跑，卡在这三件事上
新手写脚本最容易踩的就是这三个坑，我一个个说。
shebang写错是最隐蔽的。#!/bin/bash和#!/bin/sh不一样，前者告诉系统用bash解释，后者用的是sh（在很多系统上是dash）。如果你脚本里使用了bash特有语法（比如[[ ]]、数组、source），但shebang写的是#!/bin/sh，脚本可能会在奇怪的地方报错。我的建议是：如果你不确定自己用到了哪些语法，统一写#!/bin/bash，它兼容性更好。
执行权限是第二个坑。没有chmod +x，直接./test.sh会报“Permission denied”。解决办法就是加权限：chmod +x test.sh。有些教程会教你用bash test.sh来绕过权限问题，这确实可行，因为这种方式不依赖文件的可执行位，而是显式调用bash去解释文件。但这样做有个副作用：如果脚本头部有#!/bin/bash，用bash test.sh执行时shebang会被忽略，因为解释器已经被你指定了。
PATH是第三个坑。脚本里你可能会调用其他程序，如果那个程序不在PATH里，脚本就会报“command not found”。最常见的场景是脚本里有pip install之类的命令，但pip安装到了~/.local/bin，而这个目录不在系统默认PATH里。解决方法是脚本开头显式添加：export PATH=$PATH:$HOME/.local/bin。
这三个坑有一个共同逻辑：脚本本质是一个“被启动的程序”，它需要满足“可被找到”和“可被执行”两个条件。可被找到，靠路径或PATH；可被执行，靠权限位和shebang。
3.3 脚本里没有的东西：别名、交互提示、作业控制
上面对比表里提过，脚本环境里很多东西是没有的，这里展开说。
别名不生效，前面已经说了，bash在脚本模式下不读取别名定义，也不展开别名。你在~/.bashrc里配了一堆alias ll='ls -alF'，脚本里写ll一样报错。我的建议是脚本里一律用完整命令，不要依赖别名，否则换台机器脚本就跑不了。
交互提示也是脚本里不存在的东西。比如命令rm -i在交互式Shell里删除前会问你“是否确认”，但在脚本里它不会停在那里等你输入，因为脚本本身没有“人来回应”这一环。更准确地说，如果脚本里执行read命令，它会从标准输入读数据。在交互式Shell里，这个标准输入来自键盘；在脚本里，标准输入可能是空的，也可能是重定向进来的文件内容。这个差异会导致一些“卡住”的现象，后面问题排查里会讲。
作业控制也是。你在终端里按Ctrl+C、Ctrl+Z，在脚本模式下这些信号的默认处理方式可能很不一样。脚本运行中你按Ctrl+C，有时候发现没反应，那是因为前台进程组和终端会话的归属关系变了。这不是bug，是设计如此。
3.4 把交互式命令固化到脚本时的三个调整
我经常干一件事：在终端里手敲了一长串命令，验证没问题，于是就把它原封不动复制进一个.sh文件，结果一跑就报错。后来我总结了三个必须做的调整。
第一个调整是清理别名和交互式语法。把ll改成ls -l，把rm改成带完整路径或加上-f（如果确实不需要确认），把依赖用户配置的变量显式写出来。
第二个调整是增加出错处理。交互式Shell里一条命令错了，你可以看报错再敲下一条。脚本里没有这个“看报错”的机会，默认情况下命令出错后脚本还会继续往下跑，这很危险。我习惯在脚本开头加一句set -e，意思是“只要有一条命令执行失败，整个脚本立即退出”。还可以加set -u，让脚本在使用未定义变量时报错退出。这两个set选项是我写脚本的标配。
第三个调整是输出信息。交互式Shell的每个命令结果你都看得见，但脚本跑起来你不可能一直盯着。所以脚本里要有足够的输出提示，比如echo "开始备份..."、echo "备份完成，文件大小: $(du -h backup.tar.gz)"。这样脚本出错时，你能从输出日志里快速定位到底执行到哪一步了。
4. 两种方式的底层运行机制对比
4.1 父子进程与环境变量传递
很多人不理解“脚本里cd不会改变当前终端目录”这个现象。现在我用进程模型来解释，这是理解两种方式差异的关键。
每一次命令执行，在大多数情况下，Shell都会fork一个子进程去运行。你在交互式Shell里输入cd /tmp，但是cd不是外部程序，它是Shell的内置命令，直接在当前Shell进程里改变目录，所以生效。但如果你执行./test.sh，这个脚本是在一个子Shell进程里运行的。子进程从父进程继承了环境变量和当前目录，但它对环境的任何修改，比如cd、export、修改变量，都不会回传给父进程。
打个比方：你让一个下属去办事，下属出发前复制了一份你的通讯录，他在外面改了那份复印件，你手里的原件不会有任何变化。
这也是source命令和直接执行脚本的核心区别。source test.sh不是启动子进程，而是在当前Shell进程里逐行执行脚本内容，相当于“把脚本内容粘贴到当前终端里跑”。所以脚本里如果写了cd /tmp，用source执行，当前终端目录也会跟着变；用./执行，当前目录不变。
4.2 标准输入/输出/错误：交互和脚本的差异根源
Unix系统里，每个进程启动时都有三个默认通道：标准输入（stdin）、标准输出（stdout）、标准错误（stderr）。交互式Shell和脚本式Shell的差异，很大程度来自这三个通道的来源不同。
交互式Shell的标准输入是键盘，标准输出和标准错误是终端屏幕。所以你能敲命令，能看到输出，报错也会直接显示在屏幕上。脚本模式下，标准输出通常是终端（如果你直接在终端里运行脚本），但也可能是重定向到了日志文件；标准输入则往往是空，或者来自文件。
有一个经典场景：脚本里写了read -p "请输入密码: " pass，你想让它运行时让你输入密码，结果脚本跑起来直接跳过或者报错。原因就是标准输入被脚本占用了，或者脚本根本没有可用的输入源。解决办法是显式指定输入，比如read -p "..." pass < /dev/tty，强制从当前终端设备读取。这种细节在交互式Shell里完全不用考虑，因为输入天然来自键盘。
4.3 ${}、$()、shift这些语法，在两种方式下都一样吗
直接说结论：语法层面，两种方式都支持，没有区别。Shell解释器不会因为文件是脚本就禁用某些语法。${}用来做变量扩展，比如${name:-默认值}；$()用来执行命令并捕获输出，比如echo "今天日期是 $(date)"；shift用来左移位置参数，在脚本里处理命令行参数时特别常用。
但“支持”不等于“使用场景相同”。交互式Shell里，${}和$()更多是临时计算，比如你想看某个变量加个后缀是什么，直接在命令行里敲一下。脚本里，它们是逻辑的一部分，要承担参数校验、字符串处理、动态生成命令等任务。
举一个shift的例子。假设脚本这样写：
#!/bin/bash echo "第一个参数: $1" shift echo "shift之后，第一个参数变成: $1"你用./test.sh a b c运行它，第一次$1是a，shift后所有参数左移一位，原来的$2变成新的$1，也就是b。这在交互式Shell里几乎不会用到，但在脚本里写参数循环解析时是基本功。
我的建议是：语法先练熟，不用区分交互还是脚本，因为解释器不会区别对待。真正需要区别对待的，是环境、输入、输出这些运行时因素。
4.4 一个小实验：用ps观察两种方式的差异
理论讲再多，不如动手看一眼。下面这个实验很简单，你在交互式Shell里敲：
ps -o pid,ppid,comm你会看到当前正在运行的进程列表，其中有一个是bash或zsh，那就是你当前的交互式Shell。它的PPID（父进程ID）是终端程序或者你的SSH会话，而不是另一个Shell。
然后你写一个脚本：
#!/bin/bash sleep 30运行它，在另一个终端里执行：
ps -o pid,ppid,comm | grep sleep你会发现sleep进程的PPID是一个bash进程的PID，那个bash就是脚本Shell进程。这就直观展示了“脚本会在一个子Shell里执行”。
这个实验对我理解“脚本是子进程”帮助很大。很多坑，比如cd不生效、变量传不回来、后台进程被杀死，都能用这个父子进程模型解释清楚。
5. 常见问题排查与避坑实录
5.1 明明有权限，却说Permission denied
先区分两种情况。一种是你执行./test.sh，报Permission denied，说明文件没有执行权限，解决办法是chmod +x test.sh。
另一种是文件有执行权限，执行时仍然报Permission denied，比如“Permission denied”后面还跟着/bin/bash: ./test.sh: 无法执行: 需要新版本解释器或者类似的提示。这种多半是shebang写错了，比如写成了#!/bin/bash\r，末尾带了一个回车符号（从Windows复制过来的文件经常这样），系统找不到叫bash\r的解释器，就报权限或找不到命令的错误。
这个问题用cat -A test.sh可以看到端倪，如果行尾出现^M$，说明有CRLF换行符。解决办法是用sed -i 's/\r$//' test.sh清理，或者在Windows编辑器里设置换行符为LF。
5.2 source script.sh和./script.sh到底差在哪
这个问题问得特别多，我把它拆成三点回答。
第一，执行主体不同。./script.sh会启动一个子Shell来执行，source script.sh（缩写是. script.sh）在当前Shell里执行。
第二，对环境的影响不同。脚本里cd、export、修改变量，./方式执行完不影响当前终端，source方式会把修改直接“注入”到当前终端。
第三，用途不同。./适合运行独立的工具脚本，source适合加载配置文件、设置环境变量。比如你改了~/.bashrc，想让它立即生效，就得用source ~/.bashrc，而不是./.bashrc。
有一个常见坑：脚本里有一行exit，如果用source执行，它会把你的当前终端直接关掉。因为exit退出的是当前Shell进程，也就是你正在使用的那个终端Shell。我第一次踩这个坑时还以为电脑坏了。
5.3 [no write since last change] /bin/sh: wq: command not found 是怎么回事
这是个非常经典的编辑器操作错误。很多人第一次用vim，输入了wq想保存退出，结果屏幕上跳出提示：[no write since last change] /bin/sh: wq: command not found，然后shell返回1。
这个问题本质是：你进入了vim的普通模式，然后按了:进入命令行模式，此时屏幕上显示一个冒号，你输入了wq并回车，它的意思是“写入文件并退出”。之所以报“command not found”，是因为vim把命令传递给了shell去执行，而wq不是shell命令。
更常见的情况是你在Windows里习惯了Ctrl+S保存、Ctrl+Q退出，到vim里按了Ctrl+Z，然后输入wq，此时vim已经退到了后台，你面对的是shell提示符，输入wq自然找不到命令。
解决方法是记住vim的保存退出流程：先按Esc确保退出编辑模式，然后输入:wq，再按回车。如果只想保存不退出，用:w；只想退出不保存，用:q!。如果vim提示“no write since last change”，说明文件有改动但没写入，使用:wq会先写入再退出，如果写入失败则不会退出，这是保护机制。
5.4 Windows上写的脚本到Linux跑不了
这个坑我几乎每周都能碰到。在Windows上用记事本或VS Code写了一个.sh文件，传到Linux上一执行，各种诡异报错，最常见的就是/bin/bash^M: 解释器错误或者第一行命令找不到。
根源就是换行符。Windows用CRLF（回车+换行）作为行结束符，Linux用LF（换行）。Shell解析脚本时，把回车符号当成命令的一部分，于是#!/bin/bash变成了#!/bin/bash\r，系统找不到这个解释器。
解决办法我刚才提过，用sed -i 's/\r$//' 文件名清理即可。如果你经常跨平台写脚本，建议在编辑器里就设置好换行符，VS Code右下角可以切换LF/CRLF，改成LF再传上去就不会有这个问题。
还有一个相关坑：chmod权限在Windows上写的文件里不一定能设置好。在Windows上右键属性里勾了“可执行”，传到Linux并不代表权限就带过去了。正确做法是在Linux上执行chmod +x设置权限。
写在最后的个人体会
这篇文章我梳理了进入Shell的两种方式：交互式Shell和脚本式Shell。我的实际体会是，这两种方式不是对立的，而是同一个工具在不同场景下的两种形态。日常调试、排查问题、临时算点东西，用交互式Shell，灵活、即时、有反馈；批量处理、定时任务、重复劳动，用脚本式Shell，高效、稳定、可复用。
我自己养成了一个习惯：凡是需要执行超过三遍的重复命令，我就会停下来说服自己，这值得写个脚本了。不要嫌脚本初版写得丑，先让它跑通，再逐步优化，比每次手动敲命令强得多。另外，遇到“明明配置了却不生效”“命令报错原因诡异”这类问题，我建议先停下来想一个问题：当前这段代码是在交互式Shell里跑的，还是在脚本里跑的？这个答案能帮你排除一半以上的环境类问题。
最后分享一个小技巧：如果你不确定某个命令在交互式Shell和脚本里表现是否一致，可以在脚本里用set -x开启调试模式，它会打印每条命令的实际执行过程。这比对着屏幕发呆猜原因要高效得多。Shell这个东西，多踩一次坑，水平就实打实涨一块，希望这篇文章能帮你少踩几个坑。
