拓冰网站定制 
如果你经常折腾Linux不管是自己写脚本还是跑别人的项目command not found这行提示大概率见过。刚开始接触的时候我以为是系统出问题了后来才发现这一行短短的报错背后可能藏着十几种完全不同的原因。有人改了脚本权限还是报错有人把脚本从Windows拷贝过来就崩有人明明装了软件却找不到命令还有人压根没搞清楚脚本执行时和命令行交互时用的根本不是同一套逻辑。这篇就把这一类问题彻底掰开从现象到原理从排查到解决一次讲透。先明确一下场景这里说的“执行脚本报command not found”通常指的是你运行一个.sh文件或者执行某个shell命令时系统告诉你“找不到这个命令”。它和“Permission denied”、“No such file or directory”是三类不同的问题后者是权限和路径问题而command not found是shell在查找命令时彻底扑空。但有意思的是很多情况下它只是表象背后真正的原因可能是换行符、编码、环境变量、shebang甚至文件权限——这些问题中的任何一个都能让脚本在启动的第一毫秒就死掉。这篇文章既适合刚入门的Linux新手用来建立完整的排查框架也适合写过不少脚本的老手对照查漏。接下来我会从shell执行命令的基本原理开始逐步带你走一遍完整的问题拆解和实操排查流程。1. 先把机制搞明白shell到底怎么“找”命令1.1 命令查找的全过程想彻底理解command not found就得先搞清楚shell执行命令时内部做了什么。你敲下./test.sh或者bash test.sh的时候shell并不是直接就去磁盘上找这个文件它有一套固定的查找顺序。第一步shell会检查你输入的命令是不是一个“关键字”比如if、for、while这些语法结构第二步检查是不是别名alias第三步检查是不是shell内置命令builtin比如cd、echo、export最后一步才会去PATH环境变量定义的目录列表里逐个目录查找可执行文件。这里面最关键的坑就在最后一步PATH里有没有这个目录决定了shell能不能找到你的命令。PATH是一串用冒号分隔的目录路径shell会从左到右依次搜索。如果你要执行的脚本不在这些目录里而且你又没有明确写出路径比如用./指代当前目录shell就找不到它。很多人第一次写脚本习惯在Windows上一样直接敲脚本名比如myscript.sh然后在Linux上报command not found。原因很简单当前目录通常不在PATH里出于安全考虑Linux默认不把.加入PATH所以shell根本不会去当前目录找。你必须告诉它“就在当前目录下执行”也就是写成./myscript.sh。顺带说一句很多新手会把command not found和“没有执行权限”混在一起。执行权限缺失的报错通常是Permission denied而不是command not found。这两者的区别一定要记住排查方向完全不同。1.2 交互式Shell和非交互式Shell的差异另一个容易被忽略的点是你在终端里手动敲命令和脚本内部执行命令用的是两套环境。终端里的是交互式shell脚本里的是非交互式shell。交互式shell会加载~/.bashrc、/etc/profile这些配置文件而非交互式shell默认不加载这些用户级配置。也就是说你在终端里能用的命令脚本里不一定能用。典型的案例你在~/.bashrc里通过alias给某个命令起了别名或者自定义了一个函数手动敲没问题但一跑脚本就报command not found因为脚本里的子shell根本不会读取你的~/.bashrc。这一点在设计脚本时尤其要注意。脚本必须依赖标准的、可移植的命令路径而不是依赖某个用户手动配置好的环境。这也是为什么很多严谨的脚本开头都会重新定义PATH或者用绝对路径调用命令。2. 最常见的三类直接原因PATH、shebang和脚本格式2.1 PATH环境变量导致的找不到命令如果报错信息是xxx: command not found而且这个xxx是你自己写的脚本名先从PATH查起。在终端里执行echo $PATH看看当前目录也就是.是否在列表里。如果没有执行脚本请务必带上路径前缀./myscript.sh或者/绝对/路径/myscript.sh。还有一种情况需要特别留意你在安装某个软件后它的可执行文件所在的目录没有加入PATH。比如手动解压了一个绿色版的Python、Node或者某个命令行工具执行时也会报commend not found。解决方式是把这个目录追加到PATH里可以在~/.bashrc末尾加一行export PATH/opt/myapp/bin:$PATH追加完之后执行source ~/.bashrc让配置生效。注意这里用的是$PATH也就是在原有PATH前面加上新目录这是为了避免覆盖掉系统原有的命令路径。如果你写反了把$PATH放在前面那么你自定义的目录优先级会降低一旦和系统命令重名调用的可能还是旧的。我还遇到过一种很坑的情况有些安装脚本会把PATH设置到某个不存在或者被移动过的目录导致后续所有命令都找不到。这种问题有一个典型特征——报错的不只是你的脚本连ls、cp这些系统基础命令都会跟着报command not found。如果你发现基础命令都失效了优先检查PATH是否被整个覆盖或清空了。急救方式是用绝对路径调用命令比如/usr/bin/ls然后修正PATH配置。2.2 shebang行写错脚本根本无法启动shebang是指脚本第一行的#!开头的那段声明比如#!/bin/bash。它告诉系统应该用哪个解释器来执行这个脚本。如果这一行写错了或者指定的解释器路径不存在就会出现各种奇怪的现象。最常见的两种情况第一shebang写成了#!/bin/bash但你的系统里bash不在/bin下有些系统在/usr/bin解释器找不到系统自然没法执行脚本第二shebang行里带了多余的空格或参数导致解析异常。还有一种经典错误是脚本第一行是空的或者有不可见字符shebang被挤到了第二行。此时系统会认为脚本没有shebang默认用当前shell来解释执行而某些语法在当前shell里不被支持从而报错。这类问题用head -1 script.sh | cat -A就可以看到端倪cat -A能把不可见字符显示出来如果末尾看到^M$那就是Windows换行符混进来了这个下面会重点说。正确做法是写清楚绝对路径#!/bin/bash或者#!/usr/bin/env bash。后者更稳妥它通过env命令在PATH中查找bash能兼容bash不在/bin下的系统。但env方案也不是万能的——如果你的PATH被污染了它同样可能找不到解释器。2.3 CRLF换行符引发的一连串诡异问题这是从Windows环境拷脚本到Linux后最常见的问题没有之一。Windows文本文件的行尾是\r\n回车换行而Linux只认\n换行。脚本文件带着\r第一行shebang会变成#!/bin/bash\r系统拿着/bin/bash\r去找解释器自然是找不到的。这个问题的报错信息很有迷惑性。有时候直接就是command not found有时候是/bin/bash^M: bad interpreter: No such file or directory。注意看有没有^M或者\r字样。修复方法很简单一条命令搞定sed -i s/\r$// script.sh或者用dos2unix工具dos2unix script.sh修完之后用file script.sh检查输出里应该显示ASCII text而不是with CRLF line terminators。我个人的习惯是所有脚本提交到Linux环境后第一件事就是跑一遍file命令确认格式防患于未然。3. 执行方式与文件权限很多人卡在这里3.1 权限位和umask的实际影响脚本文件就算格式正确、路径也对如果你直接执行./script.sh系统还需要检查执行权限。权限不对会报Permission denied但要注意有时候报错信息会被包装成别的东西尤其是当脚本内部还要调用其他命令时排查起来更绕。查看权限用ls -l script.sh输出类似于-rw-r--r--第一个-表示这是普通文件。如果没有任何x位就说明没有执行权限。修复方式是chmod x script.sh。这里想多说一句umask。umask决定了新创建文件的默认权限。很多系统的umask是022这意味着新建文件默认权限是644rw-r--r--没有执行权限。如果你用编辑器或者重定向方式创建脚本默认就没有执行权每次都要手动chmod。这不是系统有问题是设计如此。想省事的话可以在创建脚本文件后就立刻习惯性地加上执行权限。另外要注意挂载在noexec选项下的文件系统比如某些/tmp、挂载的数据盘即使文件有x权限也不允许直接执行。如果确定文件在noexec分区要么换目录执行要么用解释器执行例如bash script.sh。这种情况在企业服务器的数据盘上特别常见。3.2 source、sh和直接执行的三个不同状态同一个脚本有几种执行方式效果完全不同。直接执行./script.sh系统依据shebang选择解释器来跑脚本运行在独立子shell中。这种方式最常用但要求文件有执行权限。bash script.sh是明确指定用bash解释器来执行文件权限无所谓只要有读权限就行。这种方式适合调试即使文件没有x权限也能跑。但它有一个坑如果脚本里的shebang写的是#!/bin/sh而你强行用bash执行某些行为会不一样sh和bash并不完全等价。source script.sh或者简写. script.sh是在当前shell进程中执行脚本而不是另起子shell。这意味着脚本里定义的变量、函数、修改的环境变量都能保留在当前shell中。但要注意source不检查执行权限也不依赖shebang——它默认用当前shell解释。所以如果你用source来运行一个为bash写的脚本而当前shell是zsh或sh也可能出现语法或命令兼容问题。什么时候用source常见场景包括修改了~/.bashrc后想立即生效、需要在当前环境里加载虚拟环境、脚本里定义了后续要用的函数等。什么时候别用source脚本结尾有exit语句的时候千万别用——exit会直接退出你当前的终端会话而不仅仅是结束脚本。这个坑我踩过exit在子shell执行时没什么影响但source执行时等于直接注销了你的登录会话。4. 进阶排查解释器缺失、拼写错误和隐藏字符4.1 解释器根本不存在的情况有时候报错不是你的脚本本身缺什么而是脚本第一行shebang指定的解释器在你的系统里压根没装。比如脚本写的是#!/usr/bin/python但你的系统只装了Python 3并没装Python 2或者没有/usr/bin/python这个链接那么系统启动脚本时会直接报错。排查方法很简单直接看shebang指定的解释器是否存在ls -l /usr/bin/python或者用command -v python查看实际的路径。如果确实不存在你需要修改shebang指向真实存在的解释器比如#!/usr/bin/python3或者用#!/usr/bin/env python3这种更灵活的写法。注意#!/usr/bin/env python这种写法虽然灵活但如果PATH混乱或者不存在该命令同样会失败。env的工作原理是在当前PATH里搜索命令找到第一个匹配的就用。好处是解释器路径不用写死坏处是它不保证用的是哪个版本。在严谨的生产脚本中很多人宁可写绝对路径也不愿意用env就是为了锁定解释器版本避免被PATH劫持。4.2 命令拼写和大小写问题command not found有时候纯粹是手滑。Linux命令严格区分大小写Python和python是两个不同的东西。脚本里的函数名、外部命令名同样区分大小写Echo和echo截然不同。这种情况虽然低级但在长脚本里特别容易发生。尤其是从网上复制脚本或者手工拼接多个片段时很容易混入全角字符或者奇怪的空格。这里分享一个实战技巧把报错的那一行复制出来单独在终端执行看能否通过。如果单独执行没问题说明问题在执行上下文或环境上如果单独执行同样报错那就是命令本身的问题。另外还要注意脚本里的变量名和命令名冲突。比如你定义了一个变量叫path然后在脚本里写$path——注意PATH和path是两个完全不同的东西。shell变量是区分大小写的$path只会输出你定义的那个变量的值而不会去解析环境变量PATH。这种小细节在复杂的shell脚本里很容易埋雷。4.3 通配符展开和引号引发的不可见问题有时候报错信息里看起来是command not found但实际原因更隐蔽。比如脚本里有这么一行file_$var.sh如果$var是个空变量实际执行时就被展开成了file_.sh这还算正常。但如果你写的是cp $file_pattern /backup/而$file_pattern里的值包含了多个文件名或者含特殊字符那么命令展开后的样子可能完全出乎意料。更麻烦的是通配符和文件名展开的顺序问题。bash在解析命令时变量展开发生在通配符展开之前。这意味着如果你把一串文件名存在变量里然后不加引号直接使用bash会优先做变量展开之后再做单词拆分和通配符展开文件名里的空格就会把参数拆碎。这经常导致“明明是五个参数传过去变成了八个”或者“某个文件名被当成命令执行了”这类诡异现象。我处理过的真实案例一个备份脚本里写的是scp $FILES userserver:/backup/结果某个文件名包含空格展开后被拆成了多个参数引发连锁错误。后面改成scp ${FILES[]} userserver:/backup/数组形式问题才解决。这里想强调一个原则在shell脚本里能用引号包起来的变量就尽量用引号包起来。虽然和有细微差别双引号内的$会被解析单引号内不会但加上引号至少能避免单词拆分和通配符展开的坑。5. 快速排查指南和实战速查表5.1 6步定位法从报错到根因的固定流程遇到command not found我建议按下面的顺序排查每一步都是上一没解决才进入下一步这样效率最高。第一步复现问题。用最原始的方式执行脚本记录完整的报错信息。不要只看第一行后面的上下文往往更有用。第二步用file命令检查脚本类型和编码格式。这一步能一次性排除CRLF和编码问题。看到with CRLF line terminators或者UTF-16之类的输出就直接修复格式。第三步检查权限。ls -l script.sh看有没有执行权限也顺便看脚本所在目录是否有权限访问。目录权限缺失会导致文件明明存在却无法读取或执行。第四步检查shebang。head -1 script.sh确认第一行内容再用command -v bash验证解释器存在于系统PATH中。第五步手动模拟执行。尝试bash script.sh如果这样能正常执行问题大概率出在shebang或执行权限上如果依然报错进一步在脚本里添加set -x打开追踪逐行观察执行过程。第六步用type -a 命令名检查命令别名、内置命令、外部命令的真实状态。单独在终端里敲这个命令看shell是如何解析它的。5.2 常见问题速查表快速匹配你的场景报错场景可能原因快速修复执行./m.sh报command not found但bash m.sh正常缺少执行权限或当前目录不在PATHchmod x m.sh或用./前缀报错信息带^M或\r脚本是Windows换行符sed -i s/\r$// m.sh或dos2unix m.sh报错的是ls、cp等基础命令PATH被污染或覆盖用/usr/bin/ls绝对路径临时调用修复PATH配置脚本能执行但内部某条命令not found脚本环境不继承用户自定义PATH在脚本开头显式export PATH...执行./python_script.py报错shebang指定的解释器路径不存在修改shebang为#!/usr/bin/env python3报错信息显示No such file or directory但文件明明存在有可能是shebang解释器缺失或文件是两种格式混合检查head -1用file验证脚本内有别名命令执行时突然失效非交互式shell不加载用户别名配置改用标准命令不要在脚本里依赖alias从网上下载的脚本一模一样但就是报错编码、隐藏字符或者被网页转换过cat -A script.sh检查末尾和特殊字符这张表覆盖了我实际工作中见过的绝大多数场景。如果你按照这个表格排查完还没解决再往深挖大概率是脚本内部的逻辑问题比如变量嵌套、命令替换反引号或$()出了问题或者脚本调用了另一个不在标准路径下的辅助脚本。6. 写个能“自愈”的脚本开头排错排得多了你会慢慢发现与其等出了问题再排查不如一开始就把脚本写得健壮一点。这里分享一个我常用的脚本模板开头能自动解决PATH、环境变量和格式问题带来的大部分麻烦。#!/usr/bin/env bash set -euo pipefail # 确保脚本在自身所在目录执行 cd $(dirname $0) # 重新构建一个干净的PATH按需修改 export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # 核心代码从这里开始解释一下这几行的用意。set -euo pipefail是我写的每个脚本都会加的三件套。-e让脚本在任意命令出错时立即退出而不是带着错误继续跑-u让脚本在使用未定义变量时直接报错退出避免变量名字写错时静默失败pipefail让管道命令中只要有一个环节失败整个管道就返回失败状态。这三条能在脚本出问题的第一时间暴露错误而不是把问题掩盖到后面。cd $(dirname $0)进入脚本自身所在的目录。这能避免一个非常常见的坑你用crontab定时执行脚本时工作目录和你在终端测试时完全不同。很多脚本出问题都是因为假设了“当前目录就是脚本所在目录”定时执行时这个假设不成立。切到固定目录后后面的相对路径、资源文件加载才可靠。重新定义PATH也不是为了炫技。定时任务里继承的PATH非常精简通常在/usr/bin:/bin没有/usr/local/bin也没有你自定义的安装目录。如果脚本里调用了安装在/usr/local/bin下的工具在定时任务里就会报command not found。显式定义PATH能让你明确知道自己依赖的是哪些目录下的命令环境变了也不怕。当然这套写法也有代价——它让环境一致性更强但同时也会忽略某些你想保留的个性化配置。如果你是要通用的基础脚本这个模板很合适如果你要的是一个能感知用户环境的交互式脚本那就不应该重新定义PATH反而要小心保留原环境变量。7. 从“能跑”到“稳定跑”给脚本做体检排错解决之后还有一件事值得做就是系统性检查脚本质量避免未来踩坑。养成用静态检查工具的习惯。shellcheck是shell脚本领域的事实标准直接通过包管理器安装apt install shellcheck或yum install shellcheck。跑一遍shellcheck script.sh它会帮你指出未加引号的变量、可移植性问题、语法歧义等——这些都是新手包括我当年的我最容易犯的错。举例来说shellcheck会警告不带引号的$var提醒你可能存在单词拆分会警告cd操作没有检查是否成功因为一旦目录切换失败后续所有相对路径操作都会在错误的目录里执行会警告for i in $(ls *.txt)这种写法是不安全的因为文件名里的空格会把它拆成多个词。这些问题都是经验积累出来的用工具代替人工记忆效率提升非常明显。另外强烈建议养成在脚本开发阶段就打开bash -x的习惯。bash -x script.sh会把每次执行的命令连同展开后的结果一起打印出来你能直观看到变量是如何被展开的、引号起了什么效果、路径最终指向哪里。调试完成后去掉-x用正常模式跑一遍确认没有遗留。再分享一个排查command not found的深层技巧如果你确实找不到任何一个逻辑上的原因试试strace工具。strace -f -e execve ./script.sh 21 | grep ENOENT可以追踪脚本进程试图执行哪些程序时出现了ENOENT文件不存在错误。这是终极手段能定位到shell到底尝试去找哪个文件失败很多表面上看不出来的问题比如某个动态库路径缺失、辅助程序路径写错都能通过strace一次性抓到。当然strace输出很吵需要先熟悉一下基本过滤方法不要被洪水般的信息淹没。最后聊一个很多人会问的问题脚本测试环境和生产环境不一致怎么办我的建议是脚本里不要写死只有你机器上才有的路径也不要用只有你机器上才装了的命令的特殊参数。我见过太多人在自己电脑上跑得飞快的脚本部署到服务器上立刻报command not found原因就是开发机装了某个工具服务器没装开发机PATH包含某个自定义目录服务器没有。要么在脚本开头明确检查依赖要么把依赖写好文档并在部署前执行一遍bash -n script.sh只做语法检查不做执行至少确保语法层没有问题。我在实际工作中的体会是command not found这个报错的迷惑性恰恰在于它太常见、太简单以至于很多人第一反应是“重启一下”或者“装个什么依赖”而忽略了一行一行拆解执行过程的必要性。真正有效的排查思路永远是确认命令由谁解析、解析时依据什么、目标文件在不在预期位置、目标文件有没有被正确格式化和授权。这套思路我用了快十年遇到任何奇怪的not found错误都管用。你把这套方法记下来下次再遇到类似提示先别慌从这台机器的PATH开始逐层往下查大概率的根因都会在五步之内原形毕露。 Linux脚本报错command not found？从Shell原理到排查思路一次讲透
如果你经常折腾Linux不管是自己写脚本还是跑别人的项目command not found这行提示大概率见过。刚开始接触的时候我以为是系统出问题了后来才发现这一行短短的报错背后可能藏着十几种完全不同的原因。有人改了脚本权限还是报错有人把脚本从Windows拷贝过来就崩有人明明装了软件却找不到命令还有人压根没搞清楚脚本执行时和命令行交互时用的根本不是同一套逻辑。这篇就把这一类问题彻底掰开从现象到原理从排查到解决一次讲透。先明确一下场景这里说的“执行脚本报command not found”通常指的是你运行一个.sh文件或者执行某个shell命令时系统告诉你“找不到这个命令”。它和“Permission denied”、“No such file or directory”是三类不同的问题后者是权限和路径问题而command not found是shell在查找命令时彻底扑空。但有意思的是很多情况下它只是表象背后真正的原因可能是换行符、编码、环境变量、shebang甚至文件权限——这些问题中的任何一个都能让脚本在启动的第一毫秒就死掉。这篇文章既适合刚入门的Linux新手用来建立完整的排查框架也适合写过不少脚本的老手对照查漏。接下来我会从shell执行命令的基本原理开始逐步带你走一遍完整的问题拆解和实操排查流程。1. 先把机制搞明白shell到底怎么“找”命令1.1 命令查找的全过程想彻底理解command not found就得先搞清楚shell执行命令时内部做了什么。你敲下./test.sh或者bash test.sh的时候shell并不是直接就去磁盘上找这个文件它有一套固定的查找顺序。第一步shell会检查你输入的命令是不是一个“关键字”比如if、for、while这些语法结构第二步检查是不是别名alias第三步检查是不是shell内置命令builtin比如cd、echo、export最后一步才会去PATH环境变量定义的目录列表里逐个目录查找可执行文件。这里面最关键的坑就在最后一步PATH里有没有这个目录决定了shell能不能找到你的命令。PATH是一串用冒号分隔的目录路径shell会从左到右依次搜索。如果你要执行的脚本不在这些目录里而且你又没有明确写出路径比如用./指代当前目录shell就找不到它。很多人第一次写脚本习惯在Windows上一样直接敲脚本名比如myscript.sh然后在Linux上报command not found。原因很简单当前目录通常不在PATH里出于安全考虑Linux默认不把.加入PATH所以shell根本不会去当前目录找。你必须告诉它“就在当前目录下执行”也就是写成./myscript.sh。顺带说一句很多新手会把command not found和“没有执行权限”混在一起。执行权限缺失的报错通常是Permission denied而不是command not found。这两者的区别一定要记住排查方向完全不同。1.2 交互式Shell和非交互式Shell的差异另一个容易被忽略的点是你在终端里手动敲命令和脚本内部执行命令用的是两套环境。终端里的是交互式shell脚本里的是非交互式shell。交互式shell会加载~/.bashrc、/etc/profile这些配置文件而非交互式shell默认不加载这些用户级配置。也就是说你在终端里能用的命令脚本里不一定能用。典型的案例你在~/.bashrc里通过alias给某个命令起了别名或者自定义了一个函数手动敲没问题但一跑脚本就报command not found因为脚本里的子shell根本不会读取你的~/.bashrc。这一点在设计脚本时尤其要注意。脚本必须依赖标准的、可移植的命令路径而不是依赖某个用户手动配置好的环境。这也是为什么很多严谨的脚本开头都会重新定义PATH或者用绝对路径调用命令。2. 最常见的三类直接原因PATH、shebang和脚本格式2.1 PATH环境变量导致的找不到命令如果报错信息是xxx: command not found而且这个xxx是你自己写的脚本名先从PATH查起。在终端里执行echo $PATH看看当前目录也就是.是否在列表里。如果没有执行脚本请务必带上路径前缀./myscript.sh或者/绝对/路径/myscript.sh。还有一种情况需要特别留意你在安装某个软件后它的可执行文件所在的目录没有加入PATH。比如手动解压了一个绿色版的Python、Node或者某个命令行工具执行时也会报commend not found。解决方式是把这个目录追加到PATH里可以在~/.bashrc末尾加一行export PATH/opt/myapp/bin:$PATH追加完之后执行source ~/.bashrc让配置生效。注意这里用的是$PATH也就是在原有PATH前面加上新目录这是为了避免覆盖掉系统原有的命令路径。如果你写反了把$PATH放在前面那么你自定义的目录优先级会降低一旦和系统命令重名调用的可能还是旧的。我还遇到过一种很坑的情况有些安装脚本会把PATH设置到某个不存在或者被移动过的目录导致后续所有命令都找不到。这种问题有一个典型特征——报错的不只是你的脚本连ls、cp这些系统基础命令都会跟着报command not found。如果你发现基础命令都失效了优先检查PATH是否被整个覆盖或清空了。急救方式是用绝对路径调用命令比如/usr/bin/ls然后修正PATH配置。2.2 shebang行写错脚本根本无法启动shebang是指脚本第一行的#!开头的那段声明比如#!/bin/bash。它告诉系统应该用哪个解释器来执行这个脚本。如果这一行写错了或者指定的解释器路径不存在就会出现各种奇怪的现象。最常见的两种情况第一shebang写成了#!/bin/bash但你的系统里bash不在/bin下有些系统在/usr/bin解释器找不到系统自然没法执行脚本第二shebang行里带了多余的空格或参数导致解析异常。还有一种经典错误是脚本第一行是空的或者有不可见字符shebang被挤到了第二行。此时系统会认为脚本没有shebang默认用当前shell来解释执行而某些语法在当前shell里不被支持从而报错。这类问题用head -1 script.sh | cat -A就可以看到端倪cat -A能把不可见字符显示出来如果末尾看到^M$那就是Windows换行符混进来了这个下面会重点说。正确做法是写清楚绝对路径#!/bin/bash或者#!/usr/bin/env bash。后者更稳妥它通过env命令在PATH中查找bash能兼容bash不在/bin下的系统。但env方案也不是万能的——如果你的PATH被污染了它同样可能找不到解释器。2.3 CRLF换行符引发的一连串诡异问题这是从Windows环境拷脚本到Linux后最常见的问题没有之一。Windows文本文件的行尾是\r\n回车换行而Linux只认\n换行。脚本文件带着\r第一行shebang会变成#!/bin/bash\r系统拿着/bin/bash\r去找解释器自然是找不到的。这个问题的报错信息很有迷惑性。有时候直接就是command not found有时候是/bin/bash^M: bad interpreter: No such file or directory。注意看有没有^M或者\r字样。修复方法很简单一条命令搞定sed -i s/\r$// script.sh或者用dos2unix工具dos2unix script.sh修完之后用file script.sh检查输出里应该显示ASCII text而不是with CRLF line terminators。我个人的习惯是所有脚本提交到Linux环境后第一件事就是跑一遍file命令确认格式防患于未然。3. 执行方式与文件权限很多人卡在这里3.1 权限位和umask的实际影响脚本文件就算格式正确、路径也对如果你直接执行./script.sh系统还需要检查执行权限。权限不对会报Permission denied但要注意有时候报错信息会被包装成别的东西尤其是当脚本内部还要调用其他命令时排查起来更绕。查看权限用ls -l script.sh输出类似于-rw-r--r--第一个-表示这是普通文件。如果没有任何x位就说明没有执行权限。修复方式是chmod x script.sh。这里想多说一句umask。umask决定了新创建文件的默认权限。很多系统的umask是022这意味着新建文件默认权限是644rw-r--r--没有执行权限。如果你用编辑器或者重定向方式创建脚本默认就没有执行权每次都要手动chmod。这不是系统有问题是设计如此。想省事的话可以在创建脚本文件后就立刻习惯性地加上执行权限。另外要注意挂载在noexec选项下的文件系统比如某些/tmp、挂载的数据盘即使文件有x权限也不允许直接执行。如果确定文件在noexec分区要么换目录执行要么用解释器执行例如bash script.sh。这种情况在企业服务器的数据盘上特别常见。3.2 source、sh和直接执行的三个不同状态同一个脚本有几种执行方式效果完全不同。直接执行./script.sh系统依据shebang选择解释器来跑脚本运行在独立子shell中。这种方式最常用但要求文件有执行权限。bash script.sh是明确指定用bash解释器来执行文件权限无所谓只要有读权限就行。这种方式适合调试即使文件没有x权限也能跑。但它有一个坑如果脚本里的shebang写的是#!/bin/sh而你强行用bash执行某些行为会不一样sh和bash并不完全等价。source script.sh或者简写. script.sh是在当前shell进程中执行脚本而不是另起子shell。这意味着脚本里定义的变量、函数、修改的环境变量都能保留在当前shell中。但要注意source不检查执行权限也不依赖shebang——它默认用当前shell解释。所以如果你用source来运行一个为bash写的脚本而当前shell是zsh或sh也可能出现语法或命令兼容问题。什么时候用source常见场景包括修改了~/.bashrc后想立即生效、需要在当前环境里加载虚拟环境、脚本里定义了后续要用的函数等。什么时候别用source脚本结尾有exit语句的时候千万别用——exit会直接退出你当前的终端会话而不仅仅是结束脚本。这个坑我踩过exit在子shell执行时没什么影响但source执行时等于直接注销了你的登录会话。4. 进阶排查解释器缺失、拼写错误和隐藏字符4.1 解释器根本不存在的情况有时候报错不是你的脚本本身缺什么而是脚本第一行shebang指定的解释器在你的系统里压根没装。比如脚本写的是#!/usr/bin/python但你的系统只装了Python 3并没装Python 2或者没有/usr/bin/python这个链接那么系统启动脚本时会直接报错。排查方法很简单直接看shebang指定的解释器是否存在ls -l /usr/bin/python或者用command -v python查看实际的路径。如果确实不存在你需要修改shebang指向真实存在的解释器比如#!/usr/bin/python3或者用#!/usr/bin/env python3这种更灵活的写法。注意#!/usr/bin/env python这种写法虽然灵活但如果PATH混乱或者不存在该命令同样会失败。env的工作原理是在当前PATH里搜索命令找到第一个匹配的就用。好处是解释器路径不用写死坏处是它不保证用的是哪个版本。在严谨的生产脚本中很多人宁可写绝对路径也不愿意用env就是为了锁定解释器版本避免被PATH劫持。4.2 命令拼写和大小写问题command not found有时候纯粹是手滑。Linux命令严格区分大小写Python和python是两个不同的东西。脚本里的函数名、外部命令名同样区分大小写Echo和echo截然不同。这种情况虽然低级但在长脚本里特别容易发生。尤其是从网上复制脚本或者手工拼接多个片段时很容易混入全角字符或者奇怪的空格。这里分享一个实战技巧把报错的那一行复制出来单独在终端执行看能否通过。如果单独执行没问题说明问题在执行上下文或环境上如果单独执行同样报错那就是命令本身的问题。另外还要注意脚本里的变量名和命令名冲突。比如你定义了一个变量叫path然后在脚本里写$path——注意PATH和path是两个完全不同的东西。shell变量是区分大小写的$path只会输出你定义的那个变量的值而不会去解析环境变量PATH。这种小细节在复杂的shell脚本里很容易埋雷。4.3 通配符展开和引号引发的不可见问题有时候报错信息里看起来是command not found但实际原因更隐蔽。比如脚本里有这么一行file_$var.sh如果$var是个空变量实际执行时就被展开成了file_.sh这还算正常。但如果你写的是cp $file_pattern /backup/而$file_pattern里的值包含了多个文件名或者含特殊字符那么命令展开后的样子可能完全出乎意料。更麻烦的是通配符和文件名展开的顺序问题。bash在解析命令时变量展开发生在通配符展开之前。这意味着如果你把一串文件名存在变量里然后不加引号直接使用bash会优先做变量展开之后再做单词拆分和通配符展开文件名里的空格就会把参数拆碎。这经常导致“明明是五个参数传过去变成了八个”或者“某个文件名被当成命令执行了”这类诡异现象。我处理过的真实案例一个备份脚本里写的是scp $FILES userserver:/backup/结果某个文件名包含空格展开后被拆成了多个参数引发连锁错误。后面改成scp ${FILES[]} userserver:/backup/数组形式问题才解决。这里想强调一个原则在shell脚本里能用引号包起来的变量就尽量用引号包起来。虽然和有细微差别双引号内的$会被解析单引号内不会但加上引号至少能避免单词拆分和通配符展开的坑。5. 快速排查指南和实战速查表5.1 6步定位法从报错到根因的固定流程遇到command not found我建议按下面的顺序排查每一步都是上一没解决才进入下一步这样效率最高。第一步复现问题。用最原始的方式执行脚本记录完整的报错信息。不要只看第一行后面的上下文往往更有用。第二步用file命令检查脚本类型和编码格式。这一步能一次性排除CRLF和编码问题。看到with CRLF line terminators或者UTF-16之类的输出就直接修复格式。第三步检查权限。ls -l script.sh看有没有执行权限也顺便看脚本所在目录是否有权限访问。目录权限缺失会导致文件明明存在却无法读取或执行。第四步检查shebang。head -1 script.sh确认第一行内容再用command -v bash验证解释器存在于系统PATH中。第五步手动模拟执行。尝试bash script.sh如果这样能正常执行问题大概率出在shebang或执行权限上如果依然报错进一步在脚本里添加set -x打开追踪逐行观察执行过程。第六步用type -a 命令名检查命令别名、内置命令、外部命令的真实状态。单独在终端里敲这个命令看shell是如何解析它的。5.2 常见问题速查表快速匹配你的场景报错场景可能原因快速修复执行./m.sh报command not found但bash m.sh正常缺少执行权限或当前目录不在PATHchmod x m.sh或用./前缀报错信息带^M或\r脚本是Windows换行符sed -i s/\r$// m.sh或dos2unix m.sh报错的是ls、cp等基础命令PATH被污染或覆盖用/usr/bin/ls绝对路径临时调用修复PATH配置脚本能执行但内部某条命令not found脚本环境不继承用户自定义PATH在脚本开头显式export PATH...执行./python_script.py报错shebang指定的解释器路径不存在修改shebang为#!/usr/bin/env python3报错信息显示No such file or directory但文件明明存在有可能是shebang解释器缺失或文件是两种格式混合检查head -1用file验证脚本内有别名命令执行时突然失效非交互式shell不加载用户别名配置改用标准命令不要在脚本里依赖alias从网上下载的脚本一模一样但就是报错编码、隐藏字符或者被网页转换过cat -A script.sh检查末尾和特殊字符这张表覆盖了我实际工作中见过的绝大多数场景。如果你按照这个表格排查完还没解决再往深挖大概率是脚本内部的逻辑问题比如变量嵌套、命令替换反引号或$()出了问题或者脚本调用了另一个不在标准路径下的辅助脚本。6. 写个能“自愈”的脚本开头排错排得多了你会慢慢发现与其等出了问题再排查不如一开始就把脚本写得健壮一点。这里分享一个我常用的脚本模板开头能自动解决PATH、环境变量和格式问题带来的大部分麻烦。#!/usr/bin/env bash set -euo pipefail # 确保脚本在自身所在目录执行 cd $(dirname $0) # 重新构建一个干净的PATH按需修改 export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # 核心代码从这里开始解释一下这几行的用意。set -euo pipefail是我写的每个脚本都会加的三件套。-e让脚本在任意命令出错时立即退出而不是带着错误继续跑-u让脚本在使用未定义变量时直接报错退出避免变量名字写错时静默失败pipefail让管道命令中只要有一个环节失败整个管道就返回失败状态。这三条能在脚本出问题的第一时间暴露错误而不是把问题掩盖到后面。cd $(dirname $0)进入脚本自身所在的目录。这能避免一个非常常见的坑你用crontab定时执行脚本时工作目录和你在终端测试时完全不同。很多脚本出问题都是因为假设了“当前目录就是脚本所在目录”定时执行时这个假设不成立。切到固定目录后后面的相对路径、资源文件加载才可靠。重新定义PATH也不是为了炫技。定时任务里继承的PATH非常精简通常在/usr/bin:/bin没有/usr/local/bin也没有你自定义的安装目录。如果脚本里调用了安装在/usr/local/bin下的工具在定时任务里就会报command not found。显式定义PATH能让你明确知道自己依赖的是哪些目录下的命令环境变了也不怕。当然这套写法也有代价——它让环境一致性更强但同时也会忽略某些你想保留的个性化配置。如果你是要通用的基础脚本这个模板很合适如果你要的是一个能感知用户环境的交互式脚本那就不应该重新定义PATH反而要小心保留原环境变量。7. 从“能跑”到“稳定跑”给脚本做体检排错解决之后还有一件事值得做就是系统性检查脚本质量避免未来踩坑。养成用静态检查工具的习惯。shellcheck是shell脚本领域的事实标准直接通过包管理器安装apt install shellcheck或yum install shellcheck。跑一遍shellcheck script.sh它会帮你指出未加引号的变量、可移植性问题、语法歧义等——这些都是新手包括我当年的我最容易犯的错。举例来说shellcheck会警告不带引号的$var提醒你可能存在单词拆分会警告cd操作没有检查是否成功因为一旦目录切换失败后续所有相对路径操作都会在错误的目录里执行会警告for i in $(ls *.txt)这种写法是不安全的因为文件名里的空格会把它拆成多个词。这些问题都是经验积累出来的用工具代替人工记忆效率提升非常明显。另外强烈建议养成在脚本开发阶段就打开bash -x的习惯。bash -x script.sh会把每次执行的命令连同展开后的结果一起打印出来你能直观看到变量是如何被展开的、引号起了什么效果、路径最终指向哪里。调试完成后去掉-x用正常模式跑一遍确认没有遗留。再分享一个排查command not found的深层技巧如果你确实找不到任何一个逻辑上的原因试试strace工具。strace -f -e execve ./script.sh 21 | grep ENOENT可以追踪脚本进程试图执行哪些程序时出现了ENOENT文件不存在错误。这是终极手段能定位到shell到底尝试去找哪个文件失败很多表面上看不出来的问题比如某个动态库路径缺失、辅助程序路径写错都能通过strace一次性抓到。当然strace输出很吵需要先熟悉一下基本过滤方法不要被洪水般的信息淹没。最后聊一个很多人会问的问题脚本测试环境和生产环境不一致怎么办我的建议是脚本里不要写死只有你机器上才有的路径也不要用只有你机器上才装了的命令的特殊参数。我见过太多人在自己电脑上跑得飞快的脚本部署到服务器上立刻报command not found原因就是开发机装了某个工具服务器没装开发机PATH包含某个自定义目录服务器没有。要么在脚本开头明确检查依赖要么把依赖写好文档并在部署前执行一遍bash -n script.sh只做语法检查不做执行至少确保语法层没有问题。我在实际工作中的体会是command not found这个报错的迷惑性恰恰在于它太常见、太简单以至于很多人第一反应是“重启一下”或者“装个什么依赖”而忽略了一行一行拆解执行过程的必要性。真正有效的排查思路永远是确认命令由谁解析、解析时依据什么、目标文件在不在预期位置、目标文件有没有被正确格式化和授权。这套思路我用了快十年遇到任何奇怪的not found错误都管用。你把这套方法记下来下次再遇到类似提示先别慌从这台机器的PATH开始逐层往下查大概率的根因都会在五步之内原形毕露。