在一台刚装好银河麒麟系统的机器上很多人第一次真正接触 Linux都不是从“安装软件”开始的而是从“软件商店报错”开始的。点开软件商店装个录屏工具或桌面整理软件结果弹出一个错误码 0006。于是去网上搜索“麒麟系统怎么安装软件”搜出来的答案充满了apt、sudo、终端这些词。等到打开终端发现自己连“换行”“切换目录”都要搜更别提什么 shell 脚本。这个场景这几年我见过太多次了。很多人会因此得出一个结论国产系统难用。但我更愿意换个角度去看——终端和 shell 不是 Windows 里那种“应急才打开”的黑色窗口它其实是麒麟系统里真正能帮你把操作沉淀下来的工作流。这篇文章不打算把shell从零讲成一本手册而是想聊清楚一件事在麒麟这类 Linux 桌面系统上终端和 shell 真正解决的不是“敲命令”的问题而是如何把零散的、重复的、容易出错的操作变成一套可复用、可排查、可长期维护的工作流。1. 装完麒麟系统后为什么第一步要回到命令行1.1 软件商店是图形入口但错误码和依赖问题会把你挡在门外银河麒麟的桌面环境做得并不差软件商店、设置中心、文件管理器都可用。但一旦遇到软件安装失败、依赖冲突、磁盘权限或者源的问题图形界面给不了太多信息。像“软件商店错误代码 0006”这种提示不同版本、不同网络环境下背后的原因可能完全不同。有的和软件源有关有的和仓库地址访问不通有关有的则是包缓存损坏。这时候唯一能帮你继续往下走的就是终端和包管理命令。很多人会觉得我只想装个软件为什么要让我学命令行原因很简单图形界面替你隐藏了“从哪下载、是否冲突、装到哪去”这些细节但也会在异常时把所有细节也一起藏起来。终端命令虽然不友好但它会告诉你依赖缺了什么、源能不能访问、哪个包出了问题。1.2 apt 不是魔法它是让安装过程“可重复”的基础在常见的 Debian 系麒麟系统里安装软件最常用的命令结构是sudo apt update sudo apt install 软件包名先解释一下为什么要有apt update。它不装软件但会更新本地的软件包索引。如果你略过这一步直接apt install很可能因为索引过期而找不到包或者装到的是旧版本。索引就像一份目录安装之前先更新目录才对得上号。卸载软件对应的是sudo apt remove 软件包名系统更新则通常是sudo apt update sudo apt upgrade如果只是装一个录屏软件、桌面整理工具这类小型应用软件商店会更快但如果要装编译工具链、Python 库、开发依赖或者要处理“装 A 需要先装 B 的某个版本”这种连锁关系命令行才真正有优势。因为它会明确告诉你依赖树和冲突点。注意不要一上来就到处复制网上的apt源配置。先确认当前源是否可用、网络是否正常再决定要不要换源。不同版本的麒麟系统对应源策略不一定相同擅自修改可能让后续所有安装都失效。1.3 安装软件遇到错误时最该先做的是“看日志”而不是反复重试遇到软件商店错误代码或者终端里apt install失败时正确的排查顺序是先看错误码出现的环节是搜索不到包还是下载失败还是依赖冲突再看源和网络能不能 ping 通仓库地址源配置文件里的地址是否有效看日志apt的日志通常在/var/log/apt/下软件商店的日志一般也有对应的家目录日志。拿到具体报错字段再搜比搜“0006 错误码”有效得多。最后才考虑清理缓存或换源。这里要强调一点不要反复点重试。错误码只是现象不改变现象背后的原因重试只会增加重复劳动。先让终端告诉你“为什么失败”再决定“怎么修”。2. 终端、shell、外部命令三层关系决定你的排查思路2.1 终端打不开不一定是你敲错了命令很多人在群里问“终端打不开怎么办”但这个问题本身可能就跨了好几个层次。需要先分清三层结构终端模拟器你看到的那个黑窗口程序比如麒麟桌面自带的终端、第三方终端工具。shell窗口里跑的解释器常见的是bash也可能是zsh、sh。它负责读入你的命令、解释它们、调用外部程序。外部命令ls、cd、mv、apt这些真正做事情的程序。同样一个“终端有问题”原因可能完全不在同一层现象更可能出问题的层终端窗口都打不开双击没反应终端模拟器本身、桌面组件、用户配置终端能打开但敲命令报“permission denied”shell 或文件权限命令提示“command not found”PATH 环境变量或软件未安装终端打开后立马退出提示退出代码 -1终端模拟器配置、系统资源或环境变量异常如果不去理解这三层的区别很容易把一次权限问题当成“系统坏了”来处理。这在从 Windows 转过来的用户身上尤其常见——Windows 的 cmd 和 PowerShell 相对封闭层级感不强而 Linux 终端是一个完整的解释执行环境必须先知道是哪一层出了问题才能决定修哪里。2.2 Windows 的终端报错不要直接套到麒麟上来在搜索“终端进程启动失败”时你会看到很多结果里提到conpty、winpty这些词。这里要说清楚那是 Windows 环境里的终端后端组件和麒麟系统的终端不是一回事。如果你在 Linux 环境里看到类似的“终端进程已终止退出代码 -1”不要直接拿 Windows 的解决方案来套。跨系统排查经验错位是新手最容易掉进去的坑。cmd和 Linux 终端怎么换行看起来是同类问题但实现机制完全不同。在 Linux shell 里一次多行输入通常可以用\续行或者在引号内直接回车让提示符变成次级提示符但 Windows 命令提示符的换行逻辑并不一样。所以遇到问题时先确定操作系统、终端模拟器、shell 类型再找对应的排查路径比搜到一个相似报错就复制命令要可靠得多。2.3 用第三方终端工具和 sudo要注意边界有些人会喜欢安装第三方终端模拟器比如功能更丰富的跨平台终端工具用它来替代系统自带终端。这种选择本身没有问题它确实能带来更好的标签页、主题和快捷键体验。但要注意第三方终端只是“外壳”它最终还是要调用系统里的 shell。也就是说换了终端模拟器不会让你不会用bash的问题自动消失。提到终端还有一个绕不开的词sudo。它是“以管理员权限执行”的意思但不要习惯性地在所有命令前面都加一个sudo。权限是用来限制误操作的如果你自己把权限边界抹掉后续出问题的概率会高很多。常见的“权限被拒绝”并不都是因为没有权限可能是文件没有执行权限也可能是要写的目录不可写。这时候应该看具体的文件权限和目录权限而不是直接换成 root 身份再跑一次。3. 从第一条命令到一个小工具shell 的价值在组合不在背命令3.1 不要用背命令的方式学 shell关于 shell 入门市面上有大量资料甚至能看到“shell 脚本编程 100 例”这类标题。我的态度是可以参考但要小心。如果你怀着“背完这 100 个例子就会了”的心态大概率过一阵子全忘光。shell 学习的核心不是背命令而是理解组合逻辑。命令是单词脚本是把单词组织成句子、段落和流程。举几个最常见的操作来说明。重命名文件。网上常见的搜索词是“linux 用 shell 重命名文件”很多人的第一反应是找一个 rename 命令但实际上最基础、也是最好理解的方式是mvmv old-name.txt new-name.txtmv的本意是移动但移动和重命名在文件系统层面是同一件事。把文件从一个路径移到另一个路径同时换个名字就是重命名。先理解这一点后续批量重命名时你就不会只想着找专门的 rename 工具而是知道可以用for循环配合mv来做。批量处理。比如当前目录下有一堆.txt文件想把它们全部转成.md扩展名for file in *.txt do mv $file ${file%.txt}.md done这里的逻辑是先让*.txt匹配所有文件再逐个取变量最后用${file%.txt}去掉后缀并加上新后缀。这不是什么高深技巧但它体现了 shell 脚本最基本的模式遍历、取值、变换、执行。3.2 参数处理shift和占位命令都是调试工具写稍微复杂一点的脚本时经常要处理传入参数。shift是一个很容易被忽略但很有用的内置命令。它的作用是把位置参数左移一位也就是$2变成$1$3变成$2。如果写一个需要循环处理多个参数的脚本shift会是干净的处理方式。while [ $1 ] do echo 当前参数: $1 shift done另外一个常被忽略的命令是:。它是一个 shell 内置的空操作命令什么都不做但会返回成功。它的价值主要在调试阶段——当你搭好了脚本骨架但某个分支还没写好时可以用它占位避免脚本因为缺少命令而报错。比如if [ -f ./config.ini ] then : else echo 配置文件不存在先创建默认配置 fi3.3 脚本不止是“能跑”还要注意换行、路径和权限很多人写完一个 shell 脚本在终端里运行却报错。最常见的三个原因换行符不对。在 Windows 里编辑过的脚本会带\r\n而 Linux 下期望的是\n。多余的回车符会让 shell 把\r当成命令的一部分。没有执行权限。写完脚本后只做了bash script.sh可能没问题但如果直接./script.sh就需要先chmod x script.sh。脚本目录定位错误。脚本里用了相对路径但你在其他目录里执行它导致找不到文件。如果脚本需要基于自身所在目录去定位其他文件常见做法是先获取脚本目录script_dir$(cd $(dirname $0) pwd)这行命令的逻辑是找到脚本所在目录然后切换进去并输出绝对路径。后续访问脚本同目录下的资源文件就可以基于$script_dir来拼接路径而不是依赖当前执行目录。换行、权限、路径这三个细节每个都不难但它们决定了脚本在不同的环境里能不能稳定复现。3.4 从单次操作到脚本是一条“最小可用”的路线我不建议一上来就写一个一百行的自动化脚本。更合理的路线是先用一条命令手动完成一次任务。把这条命令放到脚本文件里加一点参数化让它能处理一组同类文件。再给脚本加日志、判断和错误处理。最后才考虑批量、并发、定时执行。这样做的原因很实际单次跑通只能说明流程没有断真正麻烦的是输入变化、路径不存在、权限不对、中间某一步失败时你能不能快速定位。先跑通再变强最后才自动化。把顺序反过来多半会陷入“脚本写得很漂亮但跑不动”的困境。4. 脚本出问题时不要只搜命令要按链路排查4.1 忽略错误继续执行和严格失败退出是两种不同策略在 shell 脚本里“命令失败后怎么办”是一个绕不开的策略问题。常见的两种做法set -e这条语句会让脚本在遇到任何命令返回非零状态时立即退出。它适合你希望“一步失败不再继续”的场景比如部署流程某个步骤失败就应该停止避免带病继续。但有时候你确实希望在某个命令失败后继续执行。常见的处理方式不是关掉set -e而是给具体命令补上“失败也没关系”的标记可能失败的命令 || true|| true的意思是如果前面的命令失败了就执行后面的true而true总是返回成功这样整体状态就是成功的脚本就能继续往下走。搜索词里说的“shell 忽略错误继续执行”本质是在问这种策略。但这里要提醒的是忽略错误应该是显式行为而不是默认状态。如果整个脚本默认忽略所有错误等到一个关键步骤失败时你可能会在很后面才发现问题排查成本高得多。4.2 遇到“permission denied”先确认是权限还是执行方式“shell 权限被拒绝”是个高频搜索词。这个词经常让人误以为必须用管理员身份才能解决。实际上权限拒绝至少分好几种文件没有执行权限chmod x 文件。当前用户对目录没有写权限检查目录权限必要时用sudo。脚本或命令在某个受限上下文里运行比如某些新出的 AI 编程终端工具在调用 shell 执行命令时可能受限于它自己的权限模型。这种报错不一定是因为你没有权限而是工具本身选择了更保守的执行策略。排查顺序应该是先看你自己在终端里手动执行能不能成功。如果能再看脚本或工具调用环境是否缺了什么。如果手动执行都失败再看具体是权限、依赖还是路径问题。4.3 遇到“终端启动失败”或“退出代码 -1”先重建最小环境“终端进程已终止退出代码 -1”这种报错如果没有更多细节盲目重装系统是最差的选择。更合理的做法是确认是否所有用户都打不开终端还是只有当前用户打不开。区别在于如果当前用户配置损坏新建一个测试用户往往能快速判断。查看系统日志里的桌面和终端相关输出。尝试换一个终端模拟器。如果其他终端能正常启动说明 shell 和命令本身没问题问题很可能在原终端模拟器或其配置上。最后才考虑重置终端配置或重新安装对应组件。这种“先隔离变量”的思路也适用于很多 shell 脚本问题先排除输入再检查环境再缩小到某条具体命令最后再判断是工具边界还是自己写错。4.4 写脚本前先确认这段脚本是否真的应该存在还要提醒一件事不是所有任务都必须用 shell 脚本解决。有些操作图形界面点几下更快有些任务用 Python、Node 或专门的工具更合适有些场景单纯用终端复用工具比如 tmux就能解决“开一堆窗口还要来回切换”的痛点不一定需要写脚本。判断标准其实很简单这个操作会不会重复发生手工操作会不会容易出错出错后能不能说出具体是哪个环节失败了脚本的价值能不能超过它占用你学习和维护的时间如果四个问题里多数答案是“不会、不容易、不值得”那它可能还不是一个需要脚本化的任务。5. 把终端工作流固化下来别名、脚本库和复用边界5.1 别名是成本最低的“自定义命令”在.bashrc文件里加别名能显著减少重复输入。比如alias llls -alF alias upsudo apt update sudo apt upgrade这看起来只是“少打几个字母”但它真正的价值在于把高频、易错的命令片段变成自己熟悉的固定动作。不用记一长串参数也不用担心某个命令少了-y参数导致交互卡住。5.2 建一个自己的脚本目录比到处翻笔记更可靠随着积累你的脚本会多起来。我建议在用户目录下建一个bin目录把常用脚本放进去并把它加入PATH。这样你只需要写一个脚本加执行权限然后在任意目录都能直接调用。这比每次用到某个功能时去翻历史记录、去网上重新搜命令要稳定得多。脚本本身也要养成写注释的习惯。不是写“这行是循环”而是写“这个脚本解决什么问题、需要什么参数、输出放在哪里”。因为几个月后回来看脚本的人很可能就是你自己。5.3 终端复用不写脚本也能提升效率的收益点在热搜词里我注意到“终端复用”这四个字。它值得单独说一说。终端复用工具比如tmux解决的问题是你在终端里跑一个长任务和后续要做的事情之间的关系。常见场景包括SSH 到服务器跑一个长时间任务不想因为网络断开而中断。需要在多个终端任务之间快速切换不想反复开窗口。看日志、写命令、跑脚本同时进行想在同一个会话里管理。终端复用不是 shell 的替代品它是 shell 外层的“会话管理器”。如果刚接触可以先从“新建会话、分离会话、重新接入会话”这几个基础操作开始不需要一下子学完所有快捷键。5.4 长期使用的边界工具要为流程服务而不是流程为工具服务文章写到这里想收束一下。麒麟终端和 shell 的话题很广但长期使用下来真正有用的不是某一个命令而是你对待重复性任务的方式。命令行里积累的每一个别名、脚本、目录结构、排查经验本质上都是在把一次性的临时操作固化成一套可以重复调用、可以事后回溯的流程。反过来也不要为了炫技而过度工具化。一个三分钟就能手点完成的操作写成一个需要维护的脚本未必划算。真正值得脚本化的是那些重复次数多、手工操作容易出错、失败后定位困难的任务。新工具也会不断出现比如 AI 编程终端、新的终端模拟器、各种会话管理方案。但不管工具怎么变底层那套分层思维不会变先判断问题出在哪一层再决定怎么排查先跑通最小流程再考虑批量自动化先看重不重复、值不值得再决定要不要写脚本。如果你现在刚装好麒麟系统我的建议是别急着去背命令也别急着去复制一份超长的脚本。先打开终端敲第一条ls再看一眼当前目录里有什么。然后试着自己装一个软件亲手跑通一次apt update和apt install。等到某次重复操作让你觉得“这不应该手动做第二次”的时候再去写你的第一个 shell 脚本。那时你会真正理解终端和 shell 的价值——它们不只是一些命令而是你把经验沉淀下来的一种方式。
在一台刚装好银河麒麟系统的机器上很多人第一次真正接触 Linux都不是从“安装软件”开始的而是从“软件商店报错”开始的。点开软件商店装个录屏工具或桌面整理软件结果弹出一个错误码 0006。于是去网上搜索“麒麟系统怎么安装软件”搜出来的答案充满了apt、sudo、终端这些词。等到打开终端发现自己连“换行”“切换目录”都要搜更别提什么 shell 脚本。这个场景这几年我见过太多次了。很多人会因此得出一个结论国产系统难用。但我更愿意换个角度去看——终端和 shell 不是 Windows 里那种“应急才打开”的黑色窗口它其实是麒麟系统里真正能帮你把操作沉淀下来的工作流。这篇文章不打算把shell从零讲成一本手册而是想聊清楚一件事在麒麟这类 Linux 桌面系统上终端和 shell 真正解决的不是“敲命令”的问题而是如何把零散的、重复的、容易出错的操作变成一套可复用、可排查、可长期维护的工作流。1. 装完麒麟系统后为什么第一步要回到命令行1.1 软件商店是图形入口但错误码和依赖问题会把你挡在门外银河麒麟的桌面环境做得并不差软件商店、设置中心、文件管理器都可用。但一旦遇到软件安装失败、依赖冲突、磁盘权限或者源的问题图形界面给不了太多信息。像“软件商店错误代码 0006”这种提示不同版本、不同网络环境下背后的原因可能完全不同。有的和软件源有关有的和仓库地址访问不通有关有的则是包缓存损坏。这时候唯一能帮你继续往下走的就是终端和包管理命令。很多人会觉得我只想装个软件为什么要让我学命令行原因很简单图形界面替你隐藏了“从哪下载、是否冲突、装到哪去”这些细节但也会在异常时把所有细节也一起藏起来。终端命令虽然不友好但它会告诉你依赖缺了什么、源能不能访问、哪个包出了问题。1.2 apt 不是魔法它是让安装过程“可重复”的基础在常见的 Debian 系麒麟系统里安装软件最常用的命令结构是sudo apt update sudo apt install 软件包名先解释一下为什么要有apt update。它不装软件但会更新本地的软件包索引。如果你略过这一步直接apt install很可能因为索引过期而找不到包或者装到的是旧版本。索引就像一份目录安装之前先更新目录才对得上号。卸载软件对应的是sudo apt remove 软件包名系统更新则通常是sudo apt update sudo apt upgrade如果只是装一个录屏软件、桌面整理工具这类小型应用软件商店会更快但如果要装编译工具链、Python 库、开发依赖或者要处理“装 A 需要先装 B 的某个版本”这种连锁关系命令行才真正有优势。因为它会明确告诉你依赖树和冲突点。注意不要一上来就到处复制网上的apt源配置。先确认当前源是否可用、网络是否正常再决定要不要换源。不同版本的麒麟系统对应源策略不一定相同擅自修改可能让后续所有安装都失效。1.3 安装软件遇到错误时最该先做的是“看日志”而不是反复重试遇到软件商店错误代码或者终端里apt install失败时正确的排查顺序是先看错误码出现的环节是搜索不到包还是下载失败还是依赖冲突再看源和网络能不能 ping 通仓库地址源配置文件里的地址是否有效看日志apt的日志通常在/var/log/apt/下软件商店的日志一般也有对应的家目录日志。拿到具体报错字段再搜比搜“0006 错误码”有效得多。最后才考虑清理缓存或换源。这里要强调一点不要反复点重试。错误码只是现象不改变现象背后的原因重试只会增加重复劳动。先让终端告诉你“为什么失败”再决定“怎么修”。2. 终端、shell、外部命令三层关系决定你的排查思路2.1 终端打不开不一定是你敲错了命令很多人在群里问“终端打不开怎么办”但这个问题本身可能就跨了好几个层次。需要先分清三层结构终端模拟器你看到的那个黑窗口程序比如麒麟桌面自带的终端、第三方终端工具。shell窗口里跑的解释器常见的是bash也可能是zsh、sh。它负责读入你的命令、解释它们、调用外部程序。外部命令ls、cd、mv、apt这些真正做事情的程序。同样一个“终端有问题”原因可能完全不在同一层现象更可能出问题的层终端窗口都打不开双击没反应终端模拟器本身、桌面组件、用户配置终端能打开但敲命令报“permission denied”shell 或文件权限命令提示“command not found”PATH 环境变量或软件未安装终端打开后立马退出提示退出代码 -1终端模拟器配置、系统资源或环境变量异常如果不去理解这三层的区别很容易把一次权限问题当成“系统坏了”来处理。这在从 Windows 转过来的用户身上尤其常见——Windows 的 cmd 和 PowerShell 相对封闭层级感不强而 Linux 终端是一个完整的解释执行环境必须先知道是哪一层出了问题才能决定修哪里。2.2 Windows 的终端报错不要直接套到麒麟上来在搜索“终端进程启动失败”时你会看到很多结果里提到conpty、winpty这些词。这里要说清楚那是 Windows 环境里的终端后端组件和麒麟系统的终端不是一回事。如果你在 Linux 环境里看到类似的“终端进程已终止退出代码 -1”不要直接拿 Windows 的解决方案来套。跨系统排查经验错位是新手最容易掉进去的坑。cmd和 Linux 终端怎么换行看起来是同类问题但实现机制完全不同。在 Linux shell 里一次多行输入通常可以用\续行或者在引号内直接回车让提示符变成次级提示符但 Windows 命令提示符的换行逻辑并不一样。所以遇到问题时先确定操作系统、终端模拟器、shell 类型再找对应的排查路径比搜到一个相似报错就复制命令要可靠得多。2.3 用第三方终端工具和 sudo要注意边界有些人会喜欢安装第三方终端模拟器比如功能更丰富的跨平台终端工具用它来替代系统自带终端。这种选择本身没有问题它确实能带来更好的标签页、主题和快捷键体验。但要注意第三方终端只是“外壳”它最终还是要调用系统里的 shell。也就是说换了终端模拟器不会让你不会用bash的问题自动消失。提到终端还有一个绕不开的词sudo。它是“以管理员权限执行”的意思但不要习惯性地在所有命令前面都加一个sudo。权限是用来限制误操作的如果你自己把权限边界抹掉后续出问题的概率会高很多。常见的“权限被拒绝”并不都是因为没有权限可能是文件没有执行权限也可能是要写的目录不可写。这时候应该看具体的文件权限和目录权限而不是直接换成 root 身份再跑一次。3. 从第一条命令到一个小工具shell 的价值在组合不在背命令3.1 不要用背命令的方式学 shell关于 shell 入门市面上有大量资料甚至能看到“shell 脚本编程 100 例”这类标题。我的态度是可以参考但要小心。如果你怀着“背完这 100 个例子就会了”的心态大概率过一阵子全忘光。shell 学习的核心不是背命令而是理解组合逻辑。命令是单词脚本是把单词组织成句子、段落和流程。举几个最常见的操作来说明。重命名文件。网上常见的搜索词是“linux 用 shell 重命名文件”很多人的第一反应是找一个 rename 命令但实际上最基础、也是最好理解的方式是mvmv old-name.txt new-name.txtmv的本意是移动但移动和重命名在文件系统层面是同一件事。把文件从一个路径移到另一个路径同时换个名字就是重命名。先理解这一点后续批量重命名时你就不会只想着找专门的 rename 工具而是知道可以用for循环配合mv来做。批量处理。比如当前目录下有一堆.txt文件想把它们全部转成.md扩展名for file in *.txt do mv $file ${file%.txt}.md done这里的逻辑是先让*.txt匹配所有文件再逐个取变量最后用${file%.txt}去掉后缀并加上新后缀。这不是什么高深技巧但它体现了 shell 脚本最基本的模式遍历、取值、变换、执行。3.2 参数处理shift和占位命令都是调试工具写稍微复杂一点的脚本时经常要处理传入参数。shift是一个很容易被忽略但很有用的内置命令。它的作用是把位置参数左移一位也就是$2变成$1$3变成$2。如果写一个需要循环处理多个参数的脚本shift会是干净的处理方式。while [ $1 ] do echo 当前参数: $1 shift done另外一个常被忽略的命令是:。它是一个 shell 内置的空操作命令什么都不做但会返回成功。它的价值主要在调试阶段——当你搭好了脚本骨架但某个分支还没写好时可以用它占位避免脚本因为缺少命令而报错。比如if [ -f ./config.ini ] then : else echo 配置文件不存在先创建默认配置 fi3.3 脚本不止是“能跑”还要注意换行、路径和权限很多人写完一个 shell 脚本在终端里运行却报错。最常见的三个原因换行符不对。在 Windows 里编辑过的脚本会带\r\n而 Linux 下期望的是\n。多余的回车符会让 shell 把\r当成命令的一部分。没有执行权限。写完脚本后只做了bash script.sh可能没问题但如果直接./script.sh就需要先chmod x script.sh。脚本目录定位错误。脚本里用了相对路径但你在其他目录里执行它导致找不到文件。如果脚本需要基于自身所在目录去定位其他文件常见做法是先获取脚本目录script_dir$(cd $(dirname $0) pwd)这行命令的逻辑是找到脚本所在目录然后切换进去并输出绝对路径。后续访问脚本同目录下的资源文件就可以基于$script_dir来拼接路径而不是依赖当前执行目录。换行、权限、路径这三个细节每个都不难但它们决定了脚本在不同的环境里能不能稳定复现。3.4 从单次操作到脚本是一条“最小可用”的路线我不建议一上来就写一个一百行的自动化脚本。更合理的路线是先用一条命令手动完成一次任务。把这条命令放到脚本文件里加一点参数化让它能处理一组同类文件。再给脚本加日志、判断和错误处理。最后才考虑批量、并发、定时执行。这样做的原因很实际单次跑通只能说明流程没有断真正麻烦的是输入变化、路径不存在、权限不对、中间某一步失败时你能不能快速定位。先跑通再变强最后才自动化。把顺序反过来多半会陷入“脚本写得很漂亮但跑不动”的困境。4. 脚本出问题时不要只搜命令要按链路排查4.1 忽略错误继续执行和严格失败退出是两种不同策略在 shell 脚本里“命令失败后怎么办”是一个绕不开的策略问题。常见的两种做法set -e这条语句会让脚本在遇到任何命令返回非零状态时立即退出。它适合你希望“一步失败不再继续”的场景比如部署流程某个步骤失败就应该停止避免带病继续。但有时候你确实希望在某个命令失败后继续执行。常见的处理方式不是关掉set -e而是给具体命令补上“失败也没关系”的标记可能失败的命令 || true|| true的意思是如果前面的命令失败了就执行后面的true而true总是返回成功这样整体状态就是成功的脚本就能继续往下走。搜索词里说的“shell 忽略错误继续执行”本质是在问这种策略。但这里要提醒的是忽略错误应该是显式行为而不是默认状态。如果整个脚本默认忽略所有错误等到一个关键步骤失败时你可能会在很后面才发现问题排查成本高得多。4.2 遇到“permission denied”先确认是权限还是执行方式“shell 权限被拒绝”是个高频搜索词。这个词经常让人误以为必须用管理员身份才能解决。实际上权限拒绝至少分好几种文件没有执行权限chmod x 文件。当前用户对目录没有写权限检查目录权限必要时用sudo。脚本或命令在某个受限上下文里运行比如某些新出的 AI 编程终端工具在调用 shell 执行命令时可能受限于它自己的权限模型。这种报错不一定是因为你没有权限而是工具本身选择了更保守的执行策略。排查顺序应该是先看你自己在终端里手动执行能不能成功。如果能再看脚本或工具调用环境是否缺了什么。如果手动执行都失败再看具体是权限、依赖还是路径问题。4.3 遇到“终端启动失败”或“退出代码 -1”先重建最小环境“终端进程已终止退出代码 -1”这种报错如果没有更多细节盲目重装系统是最差的选择。更合理的做法是确认是否所有用户都打不开终端还是只有当前用户打不开。区别在于如果当前用户配置损坏新建一个测试用户往往能快速判断。查看系统日志里的桌面和终端相关输出。尝试换一个终端模拟器。如果其他终端能正常启动说明 shell 和命令本身没问题问题很可能在原终端模拟器或其配置上。最后才考虑重置终端配置或重新安装对应组件。这种“先隔离变量”的思路也适用于很多 shell 脚本问题先排除输入再检查环境再缩小到某条具体命令最后再判断是工具边界还是自己写错。4.4 写脚本前先确认这段脚本是否真的应该存在还要提醒一件事不是所有任务都必须用 shell 脚本解决。有些操作图形界面点几下更快有些任务用 Python、Node 或专门的工具更合适有些场景单纯用终端复用工具比如 tmux就能解决“开一堆窗口还要来回切换”的痛点不一定需要写脚本。判断标准其实很简单这个操作会不会重复发生手工操作会不会容易出错出错后能不能说出具体是哪个环节失败了脚本的价值能不能超过它占用你学习和维护的时间如果四个问题里多数答案是“不会、不容易、不值得”那它可能还不是一个需要脚本化的任务。5. 把终端工作流固化下来别名、脚本库和复用边界5.1 别名是成本最低的“自定义命令”在.bashrc文件里加别名能显著减少重复输入。比如alias llls -alF alias upsudo apt update sudo apt upgrade这看起来只是“少打几个字母”但它真正的价值在于把高频、易错的命令片段变成自己熟悉的固定动作。不用记一长串参数也不用担心某个命令少了-y参数导致交互卡住。5.2 建一个自己的脚本目录比到处翻笔记更可靠随着积累你的脚本会多起来。我建议在用户目录下建一个bin目录把常用脚本放进去并把它加入PATH。这样你只需要写一个脚本加执行权限然后在任意目录都能直接调用。这比每次用到某个功能时去翻历史记录、去网上重新搜命令要稳定得多。脚本本身也要养成写注释的习惯。不是写“这行是循环”而是写“这个脚本解决什么问题、需要什么参数、输出放在哪里”。因为几个月后回来看脚本的人很可能就是你自己。5.3 终端复用不写脚本也能提升效率的收益点在热搜词里我注意到“终端复用”这四个字。它值得单独说一说。终端复用工具比如tmux解决的问题是你在终端里跑一个长任务和后续要做的事情之间的关系。常见场景包括SSH 到服务器跑一个长时间任务不想因为网络断开而中断。需要在多个终端任务之间快速切换不想反复开窗口。看日志、写命令、跑脚本同时进行想在同一个会话里管理。终端复用不是 shell 的替代品它是 shell 外层的“会话管理器”。如果刚接触可以先从“新建会话、分离会话、重新接入会话”这几个基础操作开始不需要一下子学完所有快捷键。5.4 长期使用的边界工具要为流程服务而不是流程为工具服务文章写到这里想收束一下。麒麟终端和 shell 的话题很广但长期使用下来真正有用的不是某一个命令而是你对待重复性任务的方式。命令行里积累的每一个别名、脚本、目录结构、排查经验本质上都是在把一次性的临时操作固化成一套可以重复调用、可以事后回溯的流程。反过来也不要为了炫技而过度工具化。一个三分钟就能手点完成的操作写成一个需要维护的脚本未必划算。真正值得脚本化的是那些重复次数多、手工操作容易出错、失败后定位困难的任务。新工具也会不断出现比如 AI 编程终端、新的终端模拟器、各种会话管理方案。但不管工具怎么变底层那套分层思维不会变先判断问题出在哪一层再决定怎么排查先跑通最小流程再考虑批量自动化先看重不重复、值不值得再决定要不要写脚本。如果你现在刚装好麒麟系统我的建议是别急着去背命令也别急着去复制一份超长的脚本。先打开终端敲第一条ls再看一眼当前目录里有什么。然后试着自己装一个软件亲手跑通一次apt update和apt install。等到某次重复操作让你觉得“这不应该手动做第二次”的时候再去写你的第一个 shell 脚本。那时你会真正理解终端和 shell 的价值——它们不只是一些命令而是你把经验沉淀下来的一种方式。
