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
????????????????怎么会后者不卡住，而前者卡住？
还需要再进一步地学习以解释。
?
?