这个都不清楚就别说会用linux

l.darkfire

"说到底最不明白的是2点
1 source是否新开了一个进程。
  没开的说法：看现象1中的102部分
  开了的说法：看现象1中的104部分
  也许这个问题应该结合是否为前台后台等综合讨论。
2 所谓的&是否受终端的影响？终端一旦关闭则&的都将关闭（我做的实验都是这样，除非特殊的脚本能做成守护进程的方式）。主要现在网络上的帖子都是讲的fg,bg,jobs怎么用
，没有考虑到终端问题。"

1. source不开新进程，仅仅是在当前bash环境中执行另外一段bash代码，代码中的变量操作等对本环境有效。等同于.命令。
2. 本质上来说，以command &以后，这个进程就不在前台受控制了，比如你没法对它进行输入。终端关闭之所以导致&进程退出，是因为终端会在关闭时向进程发一个SIGHUP信号，进程对这个信号的默认处理方式是退出。应该也可以将终端设置成在关闭时不向进程发送SIGHUP信号，这样那些&进程就不会退出了。我的SecureCRT就不会有这种情况。

l.darkfire

root      6388  6290  0 11:02 pts/4    00:00:00 bash //运行sleep 104命令的shell,父进程为6290
这个是怎么来的

l.darkfire

6290一定以某种方式fork了6388，比如( ... )，这个表达式会fork一个新的子bash，然后在子bash里执行括号里的命令，比如以下代码就可以产生上述情况：
#!/bin/bash
( sleep 104 )

l.darkfire

在是正常的，说明你的终端在断开时没有发SIGHUP信号给进程。
说白了这是终端的特性，它在断开时，可以发SIGHUP信号也可以不发SIGHUP信号。和进程本身没有
什么关系。

l.darkfire

“对于这种说法，是不是我可以这样理解：当source command &。有后台&出现的情况，source也会出现fork的情况？”

首先source后面通常是跟一个脚本名，在当前环境下去执行脚本中的内容。
但是对于source script.sh &这种情况，bash会fork一个子进程去执行script，这是加了&后的不同之处。我也是刚才实验了一下才知道。

l.darkfire

因为当一个进程(10459)的父进程(1045死亡时，它的父进程就自动被系统设置为init(1)。
具体在父进程死亡的时候，把它的所有子进程的父进程设置为init(1)。

l.darkfire

因为当一个进程(10459)的父进程(10458 )死亡时，它的父进程就自动被系统设置为init(1)。
具体是在父进程死亡的时候，就把它的所有子进程的父进程设置为init(1)。

l.darkfire

1. source script不会fork子bash来执行。
2. source script &会fork子bash来执行。
3. 父进程A死亡后，它的子进程B的父进程全被设置为1，而不是被设置为父进程A的父进程C。

l.darkfire

互相学习呗

l.darkfire

自己死亡便向子进程发送SIGHUP的特性是终端才有的，程序自己默认并不会做这个事情，除非你自己编写一个程序这样做。