1. 看第一个终端
使用ps axf看出来,pid:2392的bash进程的子进程有个vim mysu.c ,而vim mysu.c的状态为S+,说明它在前台,但这个前台vim却没有看见。
此时我们终端输入vim mysu.c,并在命令行输入term,我们的目的是同时可以操作term和观察vim并通过ctrl+w+方向键切换term与vim,这样对于编译调试都非常方便。但是我发现:此时,ctrl+w+方向键已经失灵,无法切换,如下图:
在我没学进程之前,可能会整个关闭term重来,但是我现在从进程的角度一步步来看,为什么ctrl+w+方向键会卡住。
2. 我们来打开第二个终端(ctrl+shfit+T)
首先ps axf看一下进程层级
其中第二个bash是属于第二个终端的进程,往上看第一个bash的层级,我们发现:我们在第1步中vim的mysu.c变成了第二个vim mysu.c进程(第一个vim mysu.c没有找到),且这是一个新的进程。并且我们在第一步中命令行输入的term,组成了第二个vim与term并存的层级结构,这点应该都能看懂。
那么现在,我们在第二个终端里vim个别的文件,并且在命令行输入term,使term与vim共存,看看一个正常的term与vim共存的层级关系是怎样,再看一下ctrl+w+方向键会不会卡住。我们vim No_enter.c,如下图
发现:ctrl+w+方向键没有卡住,我们打开第三个终端,看下第二个终端(正常情况下的term与vim共存)与第一个终端(ctrl+w+方向键卡住的不正常并存现象)的层级结构的异同点,如下图:
发现:一个正常的共存(第二个终端,也就是第二个bash层级):/bin/bash是vim的子进程,和第一个终端好像有点匹配啊,第一个也就是两个这样的结构而已啊!
我再次验证了在第一个终端下,vim个别的c文件(不vim mysu.c)会不会共存下卡住,层级结构更新如下图:
发现vim exec.c和term共存依旧卡住。
小结:目前的情况看,共存的结构即:vim xx.c的子进程为/bin/bash, 这点第一个终端和第二个终端(正常)都是一样的,只是第一个进程的多了一个这样的结构,卡住了。
最后可以通过kill -9 pid号进行简单粗暴地将干掉第一个终端的多余层级,但是具体原因:
1. 为什么层级多了会卡住。
2. 明明相同的层级:
父vim exec.c 子/bin/bash和 父vim No_enter.c 子、bin/bash
怎么会后者不卡住,而前者卡住?
还需要再进一步地学习以解释。