重定向和语言级缓冲区【Linux操作系统】

重定向

进程每次新打开一个文件时，操作系统都要给它创建struct flie结构变量

然后从头开始遍历打开它的进程的PCB中的文件描述符表，找到空的就把struct flie结构变量的地址放进去

所以：
如果进程关掉一个文件之后，再打开一个新文件
那么新文件的文件描述符，就有可能会是关掉文件的文件描述符

例
标准输入的文件描述符为0，如果我把它关掉，再新打开一个文件
因为打开文件时，文件描述符的分配是从头开始遍历，见缝插针，所以新打开的文件的文件描述符就为0

---

---

重定向的原理

在操作系统层面，把文件描述符表的一个下标里面存放的struct flie结构变量地址，换成其他的文件的struct flie结构变量的地址
操作系统做的这个操作，进程不知道

例
下面的代码

先关掉标准输出（显示器），再打开文件log1.txt
那么打开log.txt的时候，给它分配的文件描述符就是1
也就是log.txt的struct flie结构变量的地址覆盖了，1下标中存储的标准输出的struct flie结构变量的地址
但是进程不知道，进程里只是用变量存储了一开始使用open打开标准输出时返回的文件描述符，即1
printf的时候，底层就用变量中存储的文件描述符调用write对文件描述符为1的文件进行写入
进程不知道1下标已经不指向标准输入了
此时向显示器写入的内容，就变成了向log1.txt中写入了
这不就是重定向？

---

---

重定向系统调用接口

dup2
头文件：unistd.h
参数表：
①fd1：拷贝本源fd（文件描述符）
②fd2：拷贝到的目标位置的fd

底层实现：
就是把文件描述符表中，下标为参数①的元素中存储的地址，拷贝覆盖到参数②下标对应的元素中

特点：
①函数完成之后，第一个参数fd1下标中，存储的地址不变，所以指向的文件不变
②第二个参数fd2，拷贝前指向的文件一般会被关闭

---

---

进程替换不会影响重定向

因为进程替换只会替换代码和数据，不会修改内核数据结构

进程替换就是最多让：
物理内存中存储的原进程的代码和数据被清空覆盖
相应的mm_struct（进程地址空间）中的虚拟地址可能会修改，页表的映射也可能修改
也就是只修改了因为代码和数据被覆盖造成的影响，其他的内核数据结构都不变

所以：
进程的PCB不变，进程PCB中的struct files_struct*类型的指针指向的结构体变量不变
那么这个结构体变量中存储的文件描述符表的内容就也不会改变

---

---

bash命令行中输入，输出，追加重定向的区别

核心区别就是：
①打开文件的方式不同
②对文件进行的操作不同

---

输出重定向

就是以只写的方式打开重定向之前的文件，再调用系统调用dup2进行把文件描述符表中下标为1的元素中的地址覆盖掉

之后再进程替换进行写入文件的操作

---

输入重定向

就是以只读的方式打开重定向之前的文件，再调用系统调用dup2进行把文件描述符表中下标为0的元素中的地址覆盖掉

之后进行读取文件的操作

之后再进程替换进行读取文件的操作

---

追加重定向

就是以追加的方式打开重定向之前的文件，再调用系统调用dup2进行把文件描述符表中下标为1的元素中的地址覆盖掉

之后再进程替换进行追加写入文件的操作

---

命令行中只支持向文件描述符为0，1，2的标准流进行>，>>，<重定向

为什么？
因为重定向是在进程替换之前进行的，bash即使解析了用户的命令，也根本不知道替换上来的进程会打开什么文件
即使知道了，在替换进程之前打开了，也没办法把文件描述符传递给替换上来的进程

所以命令行中只能重定向进程创建时就默认打开的0，1，2

---

文件描述符为2的标准错误重定向的时候，要指定文件描述符2

例如
对标准输出进行重定向是：echo xxxx>log.txt
因为标准输出的文件描述符是1，>默认只会把log.txt的struct file的地址填到1下标处
echo xxxx 1>log.txt当然也没问题

对标准错误进行重定向只能是：echo xxxx 2>log.txt
因为不指定2这个文件描述符，>默认只会把log.txt的struct file的地址填到1下标处
所以2下标位置的显示器的struct file地址不会被覆盖
指定了之后才会覆盖对应下标的struct file地址

---

标准错误流的作用是什么？

标准输出和标准错误都是把信息打印到显示器，那为什么还要有标准错误呢？

这是因为人们使用标准输出时，可以打印各种各样的信息
而人们使用标准错误时，一般只会打印某些代码出错时的错误信息

而且标准输出和标准错误虽然都是向显示器写入，但是它们两个是不同的文件，文件描述符也不同
可以根据这个特点，把它们两个打印的信息重定向到不同文件中保存，这样在调试时就可以只看标准错误输出的错误信息

例如
重定向标准输出和标准错误，分别生成日志，这样就在出现错误的时候，就可以直接查看错误日志

---

语言级缓冲区

语言级缓冲区为什么存在？

比起高级语言层面的函数操作，执行系统调用的成本时间，空间成本更高==
为什么呢？
①执行系统调用时需要进行内核态和用户态之间的切换
②内核的安全检查比库函数严格的多，需要花费更多时间

所以高级语言为了提高效率，降低成本，就会尽可能减少调用系统调用

printf，fprintf，scanf，fscanf等需要向文件/外设写入（读取）的IO语言接口，要IO的话又一定要调用系统调用

和内核级缓冲区存在的原因一样
如果每次printf/scanf都调用系统调用，那么效率无疑会降低
所以语言层面IO的时候，也建立了语言级缓冲区
先把printf/scanf写入（读取）到的内容放进语言级缓冲区，累积到一定程度/时机合适时，再使用一次系统调用拷贝到内核级缓冲区

所以printf/scanf的作用和系统调用read和write的作用一样：都只有拷贝的作用

---

语言级缓冲区什么时候刷新？

向显示器文件写入时：

采用行刷新[即遇到\n就把对应的语言级缓冲区中的内容刷新到内核缓冲区中]（内核级缓冲区对显示器文件也是行刷新）

注意：
输出重定向到1的普通文件不会行刷新
因为操作系统检测的是文件类型，是存储在struct file中的，重定向的时候相当于把struct file换掉了

为什么呢？
因为显示器是用户最想快速看到/最能直观感受到IO结果的地方

比如用户对游戏的帧率的要求，就是对显示器IO速度的要求
所以向显示器文件刷新的速度必须要快

---

向普通文件写入（读取）时：

缓冲区写满了或者长时间不写了才刷新