要让python脚本像命令一样运行，首先需使用chmod +x my_script.py赋予可执行权限；2. 然后在脚本首行添加shebang行如#!/usr/bin/env python3以指定解释器；3. 若需全局调用，应将脚本移至系统path包含的目录，推荐个人用户使用~/bin，系统级脚本则放/usr/local/bin，并确保路径已加入path环境变量且脚本具备执行权限，最终实现任意目录下直接通过脚本名运行。
在Linux系统中，要让一个Python脚本能够像普通命令一样直接运行，核心就是两步：首先，你需要告诉系统这个文件是一个可执行的程序，而不是普通的数据文件；其次，你还要指明系统应该用哪个解释器来运行它。这两点做到了，你的Python脚本就能直接被系统识别并执行了。
解决方案
让Python脚本在Linux上具备可执行权限，并能像命令一样运行，这背后其实涉及到了文件权限和系统路径的理解。
首先，最直接的步骤是给你的Python脚本文件添加执行权限。在Linux里，文件权限是通过
chmod命令来管理的。假设你的脚本名叫
my_script.py，你只需要在终端输入：
立即学习“Python免费学习笔记（深入）”；
chmod +x my_script.py
这行命令的意思是“给
my_script.py文件添加（
+）可执行（
x）权限”。执行完这一步，当你尝试运行它时，可能会遇到另一个问题：系统不知道用什么程序来打开它。这就引出了第二步，也是非常关键的一步：在脚本的开头添加一个“Shebang”行。
Shebang行是一个特殊的注释，通常长这样：
#!/usr/bin/env python3
# my_script.py
print("Hello from my executable Python script!")或者：
#!/usr/bin/python3
# my_script.py
print("Hello from my executable Python script!")这条
#!开头的行告诉Linux系统，当这个文件被执行时，应该使用
!后面指定的路径的程序来解释运行它。
python3就是我们常用的Python解释器。
完成这两步后，你就可以通过
./my_script.py（在脚本所在目录）来直接运行它了。如果你想让它像
ls、
cd这些系统命令一样，在任何目录下都能直接通过名字（比如
my_script.py）来运行，那么你需要把它放到系统PATH环境变量所包含的某个目录里，比如
/usr/local/bin或者你个人用户目录下的
~/bin（如果存在且已加入PATH）。
# 假设你已经添加了可执行权限和Shebang mv my_script.py /usr/local/bin/
这样，你就可以在任何地方直接输入
my_script.py来运行它了。这感觉就像是给你的Python脚本赋予了“生命”，让它从一个普通的文本文件变成了一个真正的“程序”。
Python脚本不设置可执行权限会遇到哪些常见问题？
在我看来，最常见的困扰就是那个经典的“Permission denied”错误。当你兴致勃勃地写完一个Python脚本，然后直接在终端输入
./my_script.py想运行它时，如果没设置可执行权限，系统就会冷冰冰地告诉你“权限不足”。这就像你递给别人一份说明书，却期望他们能直接把它当成一个可以操作的机器来用，显然是不行的。Linux系统对文件有着严格的权限管理，它默认把所有文件都看作是数据，除非你明确告诉它：“嘿，这个文件不是数据，它是一个程序，是可以运行的！”
除了权限问题，另一个不便之处在于，如果你不设置可执行权限，你就不得不每次都显式地调用Python解释器来运行你的脚本，比如
python3 my_script.py。这在开发调试阶段可能没什么，但如果你希望把这个脚本当作一个日常工具，或者集成到某个自动化流程中，每次都带上
python3前缀就显得非常笨拙和低效了。一个真正的“命令”应该是可以独立运行的，而不是总需要另一个程序来“启动”它。这不仅影响了使用的便捷性，也使得脚本在某些自动化场景下难以直接调用。
Shebang行中的#!/usr/bin/env python3
和#!/usr/bin/python3
有何区别？
这两种Shebang写法，虽然最终目的都是为了找到Python解释器，但它们在查找机制上有着微妙而重要的区别。
#!/usr/bin/python3是一种“硬编码”的方式。它直接指定了Python 3解释器在文件系统中的绝对路径。这意味着，如果你的系统上Python 3的解释器恰好就安装在这个位置，那么脚本就能正常运行。然而，如果你的Python 3安装在其他路径（比如通过
pyenv、
conda等工具安装在用户目录下），或者系统默认的Python 3路径发生了变化，那么这个脚本就可能因为找不到解释器而报错。它不够灵活，但胜在明确和直接。在一些非常受控、环境统一的服务器上，或者你知道Python解释器路径永远不会变的情况下，这种方式可能更“稳妥”，因为它避免了PATH环境变量可能带来的不确定性。
而
#!/usr/bin/env python3则显得更加“聪明”和“灵活”。这里的
env是一个程序，它的作用是在系统的
PATH环境变量中查找
python3这个可执行文件。这意味着，只要
python3在你的
PATH路径中，并且是第一个被找到的Python 3解释器，那么它就会被用来执行脚本。这种方式的好处在于，它不依赖于Python解释器的具体安装路径，只要你的
PATH配置正确，脚本就能在不同的系统或不同的Python环境中（比如虚拟环境）正常运行。在我看来，这是一种更推荐的实践，因为它增加了脚本的可移植性和鲁棒性，尤其是在你不知道脚本会在哪个具体环境下运行，或者需要支持多种Python版本共存的场景下。当然，它也可能带来一些潜在的“陷阱”，比如如果你的PATH配置不当，或者有多个
python3版本在PATH中，它可能会意外地选择了你不想用的那个。
将Python脚本添加到系统PATH路径的最佳实践是什么？
将Python脚本添加到系统PATH，让它能像系统命令一样被全局调用，这确实能极大提升工作效率。在我看来，最佳实践并不是单一的，它取决于你的使用场景和权限。
对于个人用户，我最推荐的做法是将脚本放在你的用户主目录下的
bin目录里。具体来说，就是
~/bin。很多Linux发行版默认会将
~/bin（如果存在的话）自动添加到用户的PATH环境变量中。如果你的系统没有默认添加，你可以在你的shell配置文件（比如
~/.bashrc、
~/.zshrc）中手动添加一行：
export PATH="$HOME/bin:$PATH"
然后执行
source ~/.bashrc（或
source ~/.zshrc）让配置生效。这样做的好处是，你不需要
sudo权限，所有操作都在你的用户范围内，安全且方便管理。我个人很多小工具脚本都是这么放的，用起来非常顺手。
对于系统级别的脚本，也就是希望所有用户都能直接调用的脚本，最常见的做法是将其放置在
/usr/local/bin目录下。这个目录是专门为系统管理员安装本地编译的程序或脚本而设计的，它通常在系统PATH中，且优先级高于系统自带的一些命令目录。将脚本移动到这里需要
sudo权限：
sudo mv your_script.py /usr/local/bin/
这样做的好处是所有用户都可以直接运行，但缺点是需要管理员权限，且管理起来可能不如个人目录灵活。
无论选择哪种方式，有几点是需要注意的：
- 命名规范： 给你的脚本一个有意义、无冲突的名字。避免与现有系统命令重名。
-
权限： 确保脚本在移动到目标目录后仍然具有可执行权限（
chmod +x
）。 - 依赖管理： 如果你的脚本依赖于特定的Python库，确保这些库在脚本运行的环境中是可用的。这通常意味着你可能需要考虑使用Python虚拟环境来打包你的脚本及其依赖，然后将虚拟环境中的可执行文件链接到PATH中的某个位置，或者直接激活虚拟环境来运行。
- 清晰的文档： 如果是团队协作或者未来自己可能忘记，为你的脚本写一个简单的说明，包括它的功能、用法和依赖，这能省去很多不必要的麻烦。
总的来说，选择一个最适合你使用场景的路径，并确保路径已添加到PATH中，是让你的Python脚本“活”起来的关键一步。
