企业官网建设流程全解析

1. 从“脚本缝合怪”到自动化枢纽：为什么Python要调用Shell？

在自动化运维、数据处理或者日常开发中，我们经常会遇到一种场景：手头有一个用Shell（比如Bash）写好的、功能稳定且复杂的脚本，它可能是历史遗留的“祖传”资产，也可能是调用了一堆命令行工具（如ffmpeg、imagemagick、curl）的最佳实践组合。现在，我们想在一个更“现代”或更“全能”的Python项目里复用这个脚本。直接重写？成本太高，还可能引入新Bug。这时候，让Python去“指挥”Shell脚本执行，就成了最经济、最稳妥的选择。

这不仅仅是偷懒。Python以其丰富的库和清晰的语法，擅长处理复杂的逻辑判断、数据结构（如JSON/XML解析）和网络请求。而Shell脚本，则是系统级操作、文件批量处理和调用原生命令行工具的“地头蛇”。将两者结合，Python作为“大脑”负责决策和调度，Shell作为“手脚”负责具体的脏活累活，能构建出既强大又灵活的自动化系统。从简单的定时备份，到复杂的数据流水线（用Python爬取数据，用Shell脚本调用awk/sed进行快速文本清洗，再用Python分析），这种模式无处不在。

然而，调用Shell脚本并非简单的“一键启动”。你需要考虑：如何获取脚本的执行结果？脚本运行中如果出错了，Python能知道吗？如果需要向脚本传递复杂的参数（比如包含空格的路径），该怎么处理？脚本如果运行时间很长，如何实现超时控制甚至实时交互？这些问题，正是区分“能用”和“用好”的关键。网上随手一搜os.system，就能看到大量关于“路径有空格怎么办”、“怎么获取返回值”的困惑，这恰恰说明了掌握正确方法的重要性。

接下来，我将结合多年在运维和开发中的实战经验，为你拆解Python调用Shell脚本的三种核心方式：简单粗暴的os.system、功能强大的subprocess模块，以及一种常被忽略但非常实用的“第三方工具”思路。我们会深入每种方法的骨髓，不仅告诉你命令怎么写，更会剖析其背后的进程通信机制、安全陷阱和性能考量，让你彻底明白在不同场景下该如何选择，并避开那些新手必踩的坑。

2.os.system：快速试水与遗留代码兼容

当你需要以最简单、最直接的方式执行一条Shell命令时，os.system通常是第一个映入脑海的函数。它的行为几乎和在终端里直接输入命令一模一样。

2.1 基本用法与直观感受

os.system的使用简单到令人发指：

import os # 执行一条简单的shell命令 return_code = os.system(‘echo “Hello from Shell”‘) print(f“命令返回码：{return_code}“)

运行这段代码，你会在屏幕上看到“Hello from Shell”的输出，并且return_code会是0（在Unix/Linux系统中，返回码0通常代表成功）。

它的工作流程非常“古典”：Python会启动一个新的Shell进程（通常是/bin/sh），然后将你传入的字符串整个交给这个Shell去解释执行。这意味着，你可以在字符串里使用Shell的所有特性，比如管道|、重定向>、&&逻辑连接，甚至环境变量$HOME。

# 使用Shell特性：管道和重定向 os.system(‘ps aux | grep python > python_processes.txt’)

执行后，当前目录下就会生成一个python_processes.txt文件，里面包含了系统进程中含有“python”字样的行。

2.2 深入原理：它到底返回了什么？

很多人误以为os.system返回的是命令的输出。这是一个经典的误解。它返回的是一个16位的状态码，其高8位是进程的退出状态（exit status），低8位是导致进程终止的信号编号（如果被信号杀死的话）。在Unix/Linux上，我们通常通过os.WEXITSTATUS()来获取真正的退出码。

import os return_value = os.system(‘ls /non_existent_directory’) print(f“原始返回值：{return_value}“) print(f“退出状态：{os.WEXITSTATUS(return_value)}“) # 通常非0，表示失败

对于成功的命令，退出状态是0。所以，判断一个命令是否成功执行，标准做法是检查其返回码是否为0。

那么，命令的输出去哪了？答案是：直接打印到了标准输出（stdout）和标准错误（stderr），也就是你的控制台。os.system本身并不捕获这些输出，Python代码无法直接处理它们。这是它最大的局限性。

2.3 经典“坑位”与实战应对

坑位一：路径与参数中的空格这是搜索热词os.system 有多个空格路径怎么写的直接来源。如果你要操作一个像“My Documents”这样的路径，直接拼接字符串会出问题。

# 错误示例：路径空格导致命令被拆解 file_path = ‘/path/to/My Documents/file.txt’ os.system(f‘cat {file_path}’) # 实际执行的是：cat /path/to/My Documents/file.txt # Shell会认为这是三个参数：’/path/to/My‘, ‘Documents/file.txt‘， 必然报错。

解决方案：使用引号包裹。但要注意引号的转义。

# 正确做法：用引号包裹整个路径字符串 file_path = ‘/path/to/My Documents/file.txt’ # 在Shell中，需要用单引号或双引号包裹含空格的参数 os.system(f“cat ‘{file_path}’“) # 使用单引号 # 或者 os.system(f’cat “{file_path}”‘) # 使用双引号

更稳健的做法是使用shlex.quote()函数，它会根据Shell的规则自动给字符串加上引号并进行转义。

import shlex file_path = ‘/path/to/My Documents/file.txt’ safe_path = shlex.quote(file_path) os.system(f‘cat {safe_path}’) # 现在安全了

坑位二：环境变量与当前工作目录os.system启动的子进程会继承当前Python进程的环境变量和工作目录。这有时是优点（方便），有时是缺点（污染）。

# 修改当前工作目录会影响os.system os.chdir(‘/tmp’) os.system(‘pwd’) # 输出将是 /tmp

如果你的Shell脚本依赖于特定的环境变量，需要在调用前设置好os.environ，或者直接在命令字符串中指定。

os.environ[‘MY_VAR’] = ‘special_value’ os.system(‘echo $MY_VAR’) # 会输出 special_value

坑位三：安全性——Shell注入漏洞这是最危险的一个坑。如果你的命令字符串来源于不可信的用户输入，直接使用os.system等同于敞开大门。

# 危险！用户输入直接拼接 user_input = input(“请输入文件名：”) # 假设用户输入了 `file.txt; rm -rf /` os.system(f‘cat {user_input}’) # 灾难发生！

永远不要直接将未经验证的用户输入拼接到命令中。如果必须处理动态参数，务必使用shlex.quote()进行转义，或者，更好的选择是放弃os.system，使用我们接下来要讲的subprocess模块，它可以完全避免Shell解释。

2.4 适用场景与总结

尽管有诸多限制，os.system依然有其用武之地：

• 快速原型与调试：在写脚本的初期，快速验证一条命令是否可行。
• 执行简单的、一次性的系统命令：比如清屏os.system(‘clear’)，或者打开一个文件os.system(‘open file.pdf’)（在Mac上）。
• 维护遗留代码：很多老脚本用了它，在不重构的情况下保持兼容。

一句话心得：把os.system看作一个“执行并忘记”的快捷方式。当你不需要捕获输出、不关心精细的错误处理、且命令简单安全时，用它。一旦需求超出这个范围，请毫不犹豫地转向subprocess。

3.subprocess模块：工业级控制的瑞士军刀

如果说os.system是一把水果刀，那subprocess模块就是一套完整的瑞士军刀。它是Python官方推荐用于创建子进程的模块，提供了极其丰富和精细的控制能力。从简单的命令执行到复杂的进程间通信（IPC），它都能胜任。理解subprocess，是掌握Python系统编程的关键一步。

3.1 核心函数三剑客：run,call,Popen

subprocess模块提供了不同抽象层次的函数，最常用的是这三个：

1. subprocess.run()(Python 3.5+ 推荐): 这是目前的主力军，一个高级别的封装函数，旨在满足大多数用例。它执行命令，等待命令完成，然后返回一个CompletedProcess实例，里面包含了所有结果（返回码、标准输出、标准错误）。它的API设计清晰，是新手和老手都应该优先使用的函数。
2. subprocess.call()/subprocess.check_call()/subprocess.check_output(): 这些是Python 3.5之前常用的函数，功能分别被subprocess.run()的不同参数组合所覆盖。现在虽然仍可使用，但官方推荐使用run()，因为它的行为更一致、更可预测。
3. subprocess.Popen(): 这是底层的基础类，提供了最大限度的灵活性。当你需要实现异步执行、实时交互（比如向进程的stdin发送数据）、操作文件描述符等高级功能时，才需要直接使用Popen。run()函数内部也是通过Popen实现的。

接下来，我们聚焦于最实用、最现代的subprocess.run()。

3.2subprocess.run()深度实战

让我们从一个最简单的例子开始，执行ls -l命令并获取结果：

import subprocess result = subprocess.run([‘ls’, ‘-l’], capture_output=True, text=True) print(“返回码:”, result.returncode) print(“标准输出:\n”, result.stdout) print(“标准错误:”, result.stderr)

这里有几个关键参数：

• args: 命令参数列表。强烈建议以列表形式传入，如[‘ls’, ‘-l’]。这可以避免Shell解析，从根本上防止Shell注入攻击。这也是解决os.system路径空格问题的终极方案——因为每个参数都是独立的列表项。
• capture_output=True: 告诉run()捕获子进程的标准输出(stdout)和标准错误(stderr)。如果设为False，输出会直接打印到控制台。
• text=True(或universal_newlines=True): 将捕获的输出（字节流）自动解码为字符串（Python 3.7+推荐用text）。如果不设置，result.stdout将是bytes类型。

场景一：执行Shell脚本，并处理输出和错误假设我们有一个脚本myscript.sh。

import subprocess try: # 注意，这里第一个参数是脚本解释器，第二个是脚本路径 result = subprocess.run([‘bash’, ‘myscript.sh’, ‘arg1’, ‘arg2’], capture_output=True, text=True, check=True, # 如果返回码非0，抛出CalledProcessError异常 timeout=30) # 设置超时，单位秒 print(“脚本执行成功！”) print(“输出：”, result.stdout) except subprocess.TimeoutExpired: print(“错误：脚本执行超时！”) except subprocess.CalledProcessError as e: print(f“错误：脚本执行失败，返回码{e.returncode}“) print(f“错误输出：{e.stderr}“)

• check=True: 这是一个极其有用的参数。当子进程返回非零退出码时，run()会抛出一个subprocess.CalledProcessError异常。这比手动检查returncode更符合Python的异常处理哲学，让错误处理逻辑更清晰。
• timeout: 设置命令执行的超时时间。如果子进程在指定时间内没有结束，会抛出subprocess.TimeoutExpired异常。这对于防止脚本卡死、管理资源至关重要。

场景二：处理包含空格的路径或复杂参数这是subprocess相比os.system的巨大优势。因为使用参数列表，根本不需要担心空格问题。

complex_path = ‘/home/user/My Complex Folder/file name (special).txt’ # 安全无忧 result = subprocess.run([‘cat’, complex_path], capture_output=True, text=True)

对于需要Shell特性的情况（如通配符*、环境变量扩展$HOME），可以显式使用shell=True，但必须格外小心安全性。

# 如果需要使用Shell通配符 result = subprocess.run(‘ls *.py | head -5’, shell=True, capture_output=True, text=True) # 警告：当shell=True且命令来自用户输入时，必须用shlex.quote转义！

3.3 环境变量与工作目录控制

subprocess.run()可以精确控制子进程的运行环境。

import subprocess import os # 1. 自定义环境变量 my_env = os.environ.copy() # 复制当前环境 my_env[‘PATH’] = ‘/my/custom/bin:’ + my_env[‘PATH’] # 在PATH前添加自定义路径 my_env[‘MY_SECRET_KEY’] = ‘abc123’ # 添加新变量 result = subprocess.run([‘echo’, ‘$MY_SECRET_KEY’], env=my_env, shell=True, capture_output=True, text=True) print(result.stdout) # 输出 abc123 # 2. 指定工作目录 result = subprocess.run([‘pwd’], cwd=‘/tmp’, capture_output=True, text=True) print(result.stdout) # 输出 /tmp

通过env参数，你可以提供一个全新的环境变量字典。如果提供了，子进程将只使用这个字典里的环境变量，而不会继承父进程的环境。这是一个重要的安全特性，可以创建干净的沙箱环境。cwd参数则用于指定子进程启动时的工作目录。

3.4 高级应用：实时交互与管道连接

subprocess.run()适用于“一发一收”的模式。如果需要与子进程进行实时交互（比如模拟一个终端，或者向一个持续运行的进程发送指令），就需要用到底层的Popen类。

import subprocess import time # 使用Popen启动一个长期运行的进程，比如一个简单的Python交互程序 proc = subprocess.Popen([‘python’, ‘-i’], # -i 进入交互模式 stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True) # 向子进程发送命令 proc.stdin.write(‘print(“Hello from subprocess”)\n’) proc.stdin.flush() # 确保数据被发送 # 读取输出（这里可能不完整，因为子进程可能在等待） # 更稳健的做法是使用communicate()，或者多线程读写 time.sleep(0.1) output, errors = proc.communicate(input=‘exit()\n’) # communicate会关闭stdin并等待结束 # 但对于需要持续对话的场景，communicate一次就结束了。 print(“输出:”, output)

对于复杂的交互，通常需要配合select模块或多线程来非阻塞地读写proc.stdout和proc.stdin。这属于更高级的用法，在需要自动化测试CLI工具或构建复杂工作流时会用到。

个人踩坑记录：曾经在一个数据处理流水线中，我用Popen调用一个C++程序，该程序会持续输出进度信息。我天真地用for line in proc.stdout:来读取，结果程序卡死了。原因是输出缓冲区被填满后，子进程在等待Python读取，而Python的for循环又在等待子进程输出结束，形成了死锁。解决方案是使用proc.stdout.readline()在循环中非阻塞读取，或者使用threading模块将读取操作放在单独的线程中。

3.5subprocess总结与选型指南

• 默认选择subprocess.run()：在95%的情况下，它都是最佳选择。使用参数列表、设置capture_output=True和text=True、利用check=True和timeout进行健壮性控制。
• 需要Shell特性时：谨慎使用shell=True，并确保命令字符串安全。优先考虑用Python代码实现相同的功能（如用glob模块代替*通配符）。
• 需要实时交互时：升级到subprocess.Popen，并准备好处理非阻塞I/O的复杂性。
• 需要最大性能或精细控制时：研究Popen的参数，如preexec_fn（在子进程exec前调用）、start_new_session（开启新会话）等。

subprocess模块的学习曲线稍陡，但投入是绝对值得的。它让你从“能执行命令”进化到“能精密控制进程”，是编写高质量自动化脚本的基石。

4. 第三方工具与特殊场景：站在巨人的肩膀上

虽然subprocess是官方标准，功能强大，但在某些特定场景下，直接使用它可能显得有些繁琐。这时，一些优秀的第三方库可以作为很好的补充，它们提供了更友好、更专注的API。同时，还有一些特殊的调用场景值得单独讨论。

4.1sh(或plumbum)：将命令当作函数来调用

如果你厌倦了构造参数列表和解析输出，想要一种更“Pythonic”的方式来调用Shell命令，那么sh库（或者功能类似的plumbum库）会让你眼前一亮。它的核心思想是：将系统命令包装成Python的可调用对象。

首先需要安装：pip install sh

import sh from sh import ls, git, curl # 直接导入命令 # 执行 ls -l print(ls(‘-l’)) # 直接打印输出，就像函数返回值一样 # 传递参数，自动处理空格和特殊字符 cat = sh.Command(‘cat’) print(cat(‘/path/with spaces/file.txt’)) # 无需手动引号！ # 捕获输出到变量 output = ls(‘-a’, ‘/tmp’) print(“文件列表:”, output) # 使用管道 (使用 _in 参数) from sh import grep # 模拟 ls | grep py result = grep(‘py’, _in=ls(‘/tmp’)) print(result) # 设置环境变量和工作目录 with sh.contrib.sudo(password=‘mypassword’, _with=True): ls(‘/root’) # 以sudo权限执行 # 后台执行 p = ls(‘-l’, _bg=True) # 立即返回，不等待 # ... 做其他事情 ... p.wait() # 等待进程结束 print(p.stdout) # 获取输出

sh库的魅力在于其直观性。命令就是函数，参数就是函数参数，输出就是返回值。它还内置了对常见操作（如后台运行、伪终端PTY）的支持。缺点是，它是对subprocess的封装，在极端复杂的进程交互场景下，可能不如直接使用subprocess.Popen灵活，并且它是一个外部依赖。

4.2envoy或sarge：更简洁的封装

类似sh的库还有envoy和sarge。它们的目标也是简化子进程调用。例如envoy（受Ruby的Open3启发）：

# pip install envoy (注意：可能已不维护，但设计思想值得了解) import envoy r = envoy.run(‘ls -l’) print(r.status_code) # 返回码 print(r.std_out) # 标准输出 print(r.std_err) # 标准错误

这些库在活跃度和功能完整性上可能不如sh，但它们代表了另一种API设计思路。在选择时，需要评估项目的依赖管理要求和库的维护状态。

4.3 特殊场景：调用需要终端(PTY)的程序

有些命令行程序（如sudo、ssh、vim，或者一些需要交互式密码输入的程序）必须运行在真正的伪终端（PTY）下才能正常工作。普通的subprocess.Popen(stdin=PIPE, stdout=PIPE)使用的是管道，程序会检测到自己没有连接TTY，从而改变行为（例如，sudo可能拒绝在非终端下要求密码）。

解决方案是使用pty模块（Unix系统）或第三方库如pexpect。

使用pexpect(跨平台)pexpect是自动化交互式命令行工具的利器。

import pexpect # 自动化 ssh 登录 child = pexpect.spawn(‘ssh user@hostname’) child.expect(‘password:’) # 等待提示符 child.sendline(‘mypassword’) # 发送密码 child.expect(‘$’) # 等待shell提示符 child.sendline(‘ls -l’) child.expect(‘$’) print(child.before.decode()) # 打印命令输出 child.sendline(‘exit’) child.wait()

pexpect通过匹配输出模式（expect）和发送输入（sendline）来模拟真人操作，完美解决了需要TTY的交互问题。它在自动化测试、运维脚本中非常有用。

4.4 性能考量：频繁调用与批处理

如果你需要在循环中成千上万次地调用一个非常简单的Shell命令（例如，对每个文件调用一次gzip），那么每次都用subprocess.run()启动一个新进程的开销会变得非常显著。

优化策略一：使用Shell内置命令或管道批处理尽量将操作批量化，让Shell一次处理多个项目。

# 低效：循环中多次调用 import subprocess for file in file_list: subprocess.run([‘gzip’, file]) # 高效：一次性处理 subprocess.run([‘gzip’] + file_list) # 如果gzip支持多文件输入 # 或者使用find + xargs cmd = f“find . -name ‘*.log’ -print0 | xargs -0 gzip” subprocess.run(cmd, shell=True)

优化策略二：用Python原生代码替代简单Shell命令对于极其简单的操作（如计算行数、简单文本替换），用Python实现可能比启动外部进程更快。

# 替代 wc -l with open(‘file.txt’) as f: line_count = sum(1 for _ in f) # 替代 grep ‘pattern’ file with open(‘file.txt’) as f: matching_lines = [line for line in f if ‘pattern’ in line]

优化策略三：使用subprocess.Popen复用进程对于需要反复交互的命令，可以启动一次进程，然后通过stdin/stdout管道多次通信，避免重复的进程创建开销。这常见于与数据库客户端、计算引擎等的交互。

4.5 场景化选择决策树

面对一个具体需求，如何选择？可以参考这个简单的决策流程：

1. 命令是否极其简单，且只需知道成功失败？-> 是，用os.system(仅限快速脚本)。
2. 需要捕获输出、处理错误、设置超时吗？-> 是，进入下一步。
3. 是否追求代码极简和可读性，且不介意添加依赖？-> 是，考虑使用sh库。
4. 需要与交互式程序（如ssh, sudo）进行自动化对话吗？-> 是，使用pexpect。
5. 其他所有情况-> 使用subprocess.run()。这是最通用、最标准、依赖性最低、控制力最强的选择。

记住，没有银弹。subprocess.run()因其平衡性和标准性，始终是那个最可靠的基础选项。第三方库是在此基础上，为特定场景提供的“语法糖”或“专业工具”。

5. 安全、错误处理与最佳实践汇总

掌握了各种调用方法后，让我们把目光投向那些决定脚本是否健壮、安全的关键细节。很多脚本在“晴天”下运行良好，一旦遇到异常输入、环境变化或意外错误，就会崩溃或产生安全漏洞。

5.1 安全第一：永远警惕Shell注入

这是最高优先级的安全准则，值得反复强调。无论使用哪种方法，只要你的命令字符串中包含了来自外部的、未经验证的输入（用户输入、网络数据、文件内容），就必须进行处理。

• os.system和subprocess.run(shell=True)是重灾区。

  # 致命漏洞 user_filename = input(“请输入要删除的文件：”) # 用户输入：`important.txt; rm -rf /home` os.system(f‘rm {user_filename}’) # 灾难！

• 黄金法则：优先使用参数列表。subprocess.run([‘rm’, user_filename])是安全的。即使user_filename是; rm -rf /home，它也会被当作一个文件名参数传递给rm命令，而rm会试图删除一个名字里包含分号和空格的文件，而不是执行分号后的命令。

• 如果必须使用shell=True（例如需要通配符*或Shell变量$HOME），必须转义。

  import shlex user_input = ‘somefile; rm -rf /‘ # 安全做法 safe_input = shlex.quote(user_input) # 转义为 ‘somefile; rm -rf /‘ subprocess.run(f‘echo {safe_input}’, shell=True) # 现在只会输出字符串

  shlex.quote()会给字符串加上引号，并对内部的引号进行转义，确保它被Shell理解为一个完整的字符串参数。

5.2 健壮性基石：全面的错误处理

一个健壮的脚本应该能优雅地处理所有可能出现的错误，而不是直接崩溃。

• 检查返回码：这是最基本的。非零返回码通常意味着失败。

  result = subprocess.run([‘ls’, ‘/nonexistent’], capture_output=True, text=True) if result.returncode != 0: print(f“命令失败！错误：{result.stderr}“) # 执行备用方案或记录日志

• 使用check=True自动抛异常：让Python的异常处理机制来帮你。

  try: subprocess.run([‘invalid_command’], check=True, capture_output=True, text=True) except subprocess.CalledProcessError as e: print(f“命令执行失败，退出码：{e.returncode}“) print(f“错误输出：{e.stderr}“) except FileNotFoundError: print(“错误：找不到命令或脚本文件！”) # 命令本身不存在

• 处理超时：防止脚本无限期挂起。

  try: subprocess.run([‘sleep’, ‘10’], timeout=5, check=True) # 5秒后超时 except subprocess.TimeoutExpired: print(“命令执行超时，正在终止…”) # 注意：timeout过期后，子进程可能仍在运行，可以考虑发送信号终止

• 处理编码问题：当text=True时，默认使用系统本地编码。如果脚本输出包含特殊字符（如中文），最好明确指定编码。

  result = subprocess.run([‘command’], capture_output=True, text=True, encoding=‘utf-8’) # 或者处理bytes，自己解码 result = subprocess.run([‘command’], capture_output=True) output_str = result.stdout.decode(‘utf-8’, errors=‘ignore’) # 忽略无法解码的字符

5.3 实用技巧与经验之谈

1. 日志记录：在自动化任务中，记录下执行的命令、输出和错误至关重要。

   import logging logging.basicConfig(level=logging.INFO) def run_command_safe(cmd_args): logging.info(f“执行命令：{‘ ‘.join(cmd_args)}“) try: result = subprocess.run(cmd_args, check=True, capture_output=True, text=True, timeout=60) logging.info(f“命令成功，输出：{result.stdout[:200]}…“) # 只记录前200字符 return result except subprocess.CalledProcessError as e: logging.error(f“命令失败！退出码：{e.returncode}， 错误：{e.stderr}“) raise except subprocess.TimeoutExpired: logging.error(“命令执行超时”) raise

2. 使用shutil.which()检查命令是否存在：在调用外部命令前，先确认它在系统的PATH里。

   import shutil if shutil.which(‘ffmpeg’) is None: print(“错误：未找到ffmpeg，请先安装。”) sys.exit(1)

3. 临时文件与资源清理：如果脚本生成临时文件，使用tempfile模块来管理，确保即使程序崩溃，临时文件也能被清理。

   import tempfile with tempfile.NamedTemporaryFile(mode=‘w+’, suffix=‘.txt’, delete=False) as tmp: tmp.write(‘some data’) tmp.flush() # 将临时文件路径传递给Shell脚本 subprocess.run([‘my_script.sh’, tmp.name]) # 退出with块后，文件会被自动删除（delete=True时）

4. 理解缓冲：子进程的输出可能被缓冲，导致你不能立即看到。对于需要实时输出的长时任务，可以考虑：

   • 在命令中强制刷新（如python -u禁用缓冲）。
   • 使用pexpect。
   • 将stderr重定向到stdout（stderr=subprocess.STDOUT）有时有助于同步。

5. 跨平台兼容性思考：如果你的脚本需要在Windows和Unix-like系统上运行，要特别注意：

   • 路径分隔符（/vs\）。
   • 命令可用性（lsvsdir）。
   • 行结束符（\nvs\r\n）。
   • 可以考虑使用pathlib模块处理路径，使用sys.platform判断系统。

回到我们最初的话题，Python调用Shell脚本，本质上是两种强大工具的联姻。没有哪一种方法是绝对最好的，只有最适合当前场景的。对于日常任务，熟练掌握subprocess.run()的常用参数，并牢记安全准则，就足以应对绝大多数情况。当遇到特殊需求时，再想起sh、pexpect这些“特种武器”。最终的目标是写出既安全高效，又清晰易维护的脚本，让Python和Shell在各自的领域里发光发热，共同构建出可靠的自动化系统。