脚本执行时的进程名，为什么不是脚本名？而是一个-bash？
一、查看脚本是否在执行
通过查看脚本中的子进程，如调用系统的进程sleep。或调用一些程序的进程。来查看脚本是否在执行。
如我的脚本中包含循环启停程序，有sleep。这里我查询sleep可以看到他的父进程。
或筛选bash来查找，如何脚本没有进程名，默认会使用bash终端作为进程名来执行。
在调用的程序启动时，使用 pstree -p <pid>来查看进程树状图结构。从下面我们可以看出 bash(3067729) 这个进程应该就是我们的脚本执行进程。
二、原因分析
在脚本文件的第一行使用一个shebang（例如 #!/bin/bash），然后通过 ./script.sh 来执行时。正常在使用ps -ef 查询时会显示执行语句如下所示。但是这里显示的是-bash。所以可能是指定sh解释器出了问题。通过检查sh脚本第一行的shebang语句（#! /bin/bash)，发现符号为中文字符，导致指定解释器无效。系统默认使用当前打开的终端使用shell作为解释器执行。所以脚本作为了一个当前终端的子进程来运行，因此没有进程名。
执行shell脚本的方式1
查看进程相关信息的命令2
-
执行shell脚本的方式
1.
./script.sh- 执行环境：这种方式会使用脚本文件第一行指定的解释器来运行脚本（通常是
#!/bin/bash 或#!/bin/sh）。 - 当前Shell：脚本在当前Shell的子Shell中执行。
- 权限要求：脚本文件需要有执行权限（使用
chmod +x script.sh 赋予）。 - Job Control：脚本会继承当前Shell的环境变量，并且可以接收来自终端的信号（如Ctrl+C）。
2.
bash script.sh- 执行环境：明确指定使用
bash 解释器来运行脚本。 - 当前Shell：脚本在当前Shell的子Shell中执行。
- 权限要求：脚本不需要有执行权限。
- Job Control：脚本同样继承当前Shell的环境变量，并且可以接收来自终端的信号。
3.
sh script.sh- 执行环境：使用
sh 解释器来运行脚本，这通常是bash 的一个更简单的版本或者链接到其他shell。 - 当前Shell：脚本在当前Shell的子Shell中执行。
- 权限要求：脚本不需要有执行权限。
- Job Control：脚本继承当前Shell的环境变量，并且可以接收来自终端的信号。
4.
nohup ./script.sh &- 执行环境：使用
nohup 命令来运行脚本，这允许脚本在后台运行，即使关闭了终端。 - 当前Shell：脚本在当前Shell的子Shell中执行，但不受终端关闭的影响。
- 权限要求：脚本需要有执行权限。
- Job Control：脚本会忽略挂断信号（SIGHUP），通常用于长时间运行的任务，输出会被重定向到
nohup.out 文件。
5.
setsid ./script.sh- 执行环境：使用
setsid 命令来运行脚本，这会创建一个新会话，使脚本不成为当前Shell的子进程。 - 当前Shell：脚本在新会话中执行，与当前终端会话无关。
- 权限要求：脚本需要有执行权限。
- Job Control：脚本不会受到来自终端的信号影响，适用于那些需要独立于终端运行的进程。
总的来说，这些方法在执行脚本时提供了不同的控制级别和环境隔离。选择哪种方法取决于你想要如何运行脚本以及脚本执行的具体需求。 ↩
- 执行环境：这种方式会使用脚本文件第一行指定的解释器来运行脚本（通常是
-
查看进程相关信息的命令
top -p
查看实时的系统进程信息
cat /proc/
/status 查看proc文件系统中关于进程的信息
cat /proc/
/cmdline 查看启动该进程的完整命令行
ls -l /proc/
/cwd 查看进程的工作目录 （通过这个命令也能知道pid 3067729就是我们的脚本进程）
strace -p
跟踪进程执行时的系统调用和接收到的信号
lsof -p
查看进程打开的文件
↩
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
