linux下c语言用execl使用vim 打开一个文件,出现了神奇的读错误的解答

我认为使用execl函数可以去使用vim。但是却出现了神奇的读错误,整个终端崩了。


#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<fcntl.h>
#include<unistd.h>
int main()
{
    
       pid_t pid;
    
    pid=fork();

    if(pid==-1){
    
    
        perror("fork error");
        exit(1);
    }
     if(pid==0){
    
    
        //  execl("/bin/ls","/bin/ls","-l",NULL);
        // execl("./a.out","./a.out",NULL);
        //  execlp("ls","ls","-l",NULL);
        close(open("test.c",O_CREAT|O_RDWR|O_APPEND,0644));
        execl("/usr/bin/vim","/usr/bin/vim","test.c",NULL);
        
        //  perror("execl");
        //  exit(1);
    }
     if(pid>0){
    
    
         sleep(1);
        printf("mychild:%d,myid =%d ,myparid=%d\n",pid,getpid(),getppid());
    }
}

在这里插入图片描述
网友的解答:父进程退出后,子进程就变成了孤儿进程,由init进程收养,成为了后台进程。但此时因为父进程退出,终端的控制权还给了shell,标准输入此时是shell进程在读,但fork的子进程因为继承了父进程的文件描述符,此时vim的标准输入也是指向终端,在终端输入的字符只能由前台进程读取,所以vim出错。上面测试的几个程序只用到了标准输出,所以看不到这个现象
就是说此时的vim想要去读终端中的数据,出现错误。

而若用execl去执行ls则是执行输出,想想ls的确是在终端输出的,而vim的输入却更像在一个新的shell中去读。

今天在用myshell的时候忽然发现我的myshell怎么可以vim,发现我的父进程wait子进程,vim是一个持续的进程,而上面程序却是sleep,父进程过早退出。从而出现了vim和shell同时争夺标准输入的问题。

因此父进程wait就完事了!

猜你喜欢

转载自blog.csdn.net/adlatereturn/article/details/105452737