linux执行.sh脚本有三种主要方式：一是显式调用解释器（如bash script.sh），无需执行权限，忽略shebang，适合测试；二是路径执行（./script.sh），需chmod +x赋权并依赖正确shebang，在子shell中运行；三是source或.命令，在当前shell执行，可修改环境变量。
.sh 文件不是“安装包”，它只是 Shell 脚本——一段可执行的文本命令。Linux 没有“安装 .sh 文件”这回事，只有「执行」或「使用」它。
你真正需要做的，是判断这个 .sh 文件想干什么，再决定怎么安全、正确地运行它。
为什么直接 ./xxx.sh 会报 Permission denied？
因为 Linux 不靠 .sh 后缀识别可执行性，而是看文件权限位里的 x（执行）标志。默认新建的 .sh 文件没有 x 权限。
- 加执行权限：用
chmod u+x script.sh（只给所有者加，更安全） - 别用
chmod 777 script.sh—— 这会让任何人读、写、执行，有严重安全风险 - 如果脚本在 U 盘（FAT32）或 NFS 挂载点上，可能根本无法设
x权限，此时必须换方式运行
bash script.sh 和 ./script.sh 的区别在哪？
这是最常被混淆的点，本质是两种完全不同的调用机制：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
-
./script.sh：系统读首行#!/bin/bash（shebang），然后按该路径调用解释器。如果 shebang 写成#!/usr/bin/env zsh但机器没装zsh，就报No such file or directory（注意：不是脚本找不到，是解释器路径错了） -
bash script.sh：强制用当前环境的bash执行，完全忽略 shebang。适合快速验证逻辑，但可能掩盖兼容性问题（比如脚本用了[[却声明#!/bin/sh，而/bin/sh实际是dash）
执行前静默退出或报 bad interpreter？查换行符和 BOM
脚本明明有权限、路径也对，却没反应、或报奇怪错误，大概率是隐藏字符问题：
- Windows 编辑保存的脚本带
\r\n（CRLF）换行符，Linux 的bash会把末尾的\r当作解释器路径一部分，导致bad interpreter: No such file or directory - 用
dos2unix script.sh或sed -i 's/\r$//' script.sh修复 - VS Code 等编辑器若保存为 UTF-8 with BOM，BOM 字节会出现在
#!前，让系统完全识别不出 shebang —— 改用 UTF-8 without BOM 保存
为什么输入 script.sh 就报 command not found？
因为 shell 只在 $PATH 列出的目录里找命令，当前目录（.）默认不在 $PATH 中。这是刻意的安全设计，防止误执行恶意同名文件。
- 正确写法永远是
./script.sh（相对路径）或/full/path/to/script.sh（绝对路径） - 临时加当前目录到 PATH：
PATH="$PWD:$PATH" script.sh—— 仅调试可用，切勿写进自动化流程 - 如果脚本要被多个地方调用，应把它放到
/usr/local/bin/并确保有执行权限，而不是改PATH
