请移步到这： http://note.youdao.com/noteshare?id=7f6bffa97acbf1a2099b9287ebb34fb0&sub=9AA2AA2101484DF4B07DE727A2B8034A 3.1.1.应用编程框架介绍   (1)整个嵌入式linux核心课程包括5个点，按照学习顺序依次是：裸机、C高级、uboot和系统移植、linux应用编程和网络编程、驱动。 (2)典型的嵌入式产品就是基于嵌入式linux操作系统来工作的。典型的嵌入式产品的研发过程就是；第一步让linux系统在硬件上跑起来（系统移植工作），第二步基于linux系统来开发应用程序实现产品功能。 (3)基于linux去做应用编程，其实就是通过调用linux的系统API来实现应用需要完成的任务。   系统调用之底层文件I/O操作 1、linux常用文件IO接口 (1)open、close、write、read、lseek   2、文件操作的一般步骤 (1)在linux系统中要操作一个文件，一般是先open打开一个文件，得到一个文件描述符，然后对文件进行读写操作（或其他操作），最后close关闭文件即可   (2)强调一点：我们对文件进行操作时，一定要先打开文件，打开成功后才能去操作（如果打开本身失败，后面就不用操作了）；最后读写完成之后一定要close关闭文件，否则可能会造成文件损坏。   (3)文件平时是存在块设备中的文件系统中的，我们把这种文件叫静态文件。 当我们去open打开一个文件时， linux内核做的操作包括： 1.内核在进程中建立了一个打开文件的数据结构，记录下我们打开的这个文件； 2.内核在内存中申请一段内存， 3.将静态文件的内容从块设备中读取到内存中特定地址管理存放（叫动态文件）。   (4)打开文件后，以后对这个文件的读写操作，都是针对内存中这一份动态文件的，而并不是针对静态文件的。 当我们对动态文件进行读写后，此时内存中的动态文件和块设备中的静态文件就不同步了， 当我们close关闭动态文件时，close内部内核将内存中的动态文件的内容去更新（同步）块设备中的静态文件。   (5)常见的一些现象： 第一个：打开一个大文件时比较慢 第二个：我们写了一半的文件，如果没有点保存直接关机/断电，重启后文件内容丢失。   (6)为什么要这么设计？ 以为块设备本身有读写限制（回忆NnadFlash、SD等块设备的读写特征），本身对块设备进行操作非常不灵活。 而内存可以按字节为单位来操作，而且可以随机操作（内存就叫RAM，random），很灵活。所以内核设计文件操作时就这么设计了。   重要概念：文件描述符 简介： 内核（kernel）利用文件描述符（file descriptor）来访问文件。 1.文件描述符是非负整数。打开现存文件或新建文件时，内核会返回一个文件描述符。读写文件也需要使用文件描述符来指定待读写的文件。 2.实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。在程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。但是文件描述符这一概念往往只适用于UNIX、Linux这样的操作系统。 3.习惯上， 标准输入（standard input）的文件描述符是 0， 标准输出（standard output）是 1， 标准错误（standard error）是 2。 尽管这种习惯并非Unix内核的特性，但是因为一些 shell 和很多应用程序都使用这种习惯，因此，如果内核不遵循这种习惯的话，很多应用程序将不能使用。 4.文件描述符的有效范围是 0 到 OPEN_MAX。一般来说，每个进程最多可以打开 64 个文件（0 — 63）。对于 FreeBSD 5.2.1、Mac OS X 10.3 和 Solaris 9 来说，每个进程最多可以打开文件的多少取决于系统内存的大小，int 的大小，以及系统管理员设定的限制。Linux 2.4.22 强制规定最多不能超过 1,048,576 。 5.文件描述符与包括相关信息（如文件的打开模式、文件的位置类型、文件的初始类型等）的文件对象相关联，这些信息被称作文件的上下文。   如何创建文件描述符 1.进程获取文件描述符最常见的方法是通过本机子例程open或create获取或者通过从父进程继承。后一种方法允许子进程同样能够访问由父进程使用的文件。 2.文件描述符对于每个进程一般是唯一的。 3.当用fork子例程创建某个子进程时，该子进程会获得其父进程所有文件描述符的副本，这些文件描述符在执行fork时打开。在由fcntl、dup和dup2子例程复制或拷贝某个进程时，会发生同样的复制过程。 4.对于每个进程，操作系统内核在u_block结构中维护文件描述符表，所有的文件描述符都在该表中建立索引。   缺点: 1.在非UNIX/Linux操作系统上(如Windows NT)，无法基于这一概念进行编程。 2.由于文件描述符在形式上不过是个整数，当代码量增大时，会使编程者难以分清哪些整数意味着数据，哪些意味着文件描述符。因此，完成的代码可读性也就会变得很差。   文件描述符与文件指针的区别 https://blog.csdn.net/dream_1996/article/details/71433972   (1)文件描述符其实实质是一个数字，这个数字在一个进程中表示一个特定的含义， 当我们open打开一个文件时，操作系统在内存中构建了一些数据结构来表示这个动态文件， 然后返回给应用程序一个数字作为文件描述符，这个数字就和我们内存中维护这个动态文件的这些数据结构挂钩绑定上了， 以后我们应用程序如果要操作这一个动态文件，只需要用这个文件描述符进行区分。   (2)一句话讲清楚文件描述符：文件描述符就是用来区分一个程序打开的多个文件的。 (3)注意： 1.文件描述符的作用域就是当前进程，出了当前进程这个文件描述符就没有意义了 2.不同文件在不同进程中打开，它的文件描述符不一样     3.1.3.一个简单的文件读写实例 3.1.3.1、打开文件与关闭文件 (1)linux中的文件描述符fd的合法范围是0或者一个正正数，不可能是一个负数。 (2)open返回的fd程序必须记录好，以后向这个文件的所有操作都要靠这个fd去对应这个文件，最后关闭文件时也需要fd去指定关闭这个文件。如果在我们关闭文件前fd丢掉了那就惨了，这个文件没法关闭了也没法读写了。   3.1.3.2、实时查man手册 (1)当我们写应用程序时，很多API原型都不可能记得，所以要实时查询，用man手册 (2)man 1 xx查linux shell命令，man 2 xxx查API， man 3 xxx查库函数   3.1.3.3、读取文件内容 (1)ssize_t read(int fd, void *buf, size_t count); fd表示要读取哪个文件，fd一般由前面的open返回得到 buf是应用程序自己提供的一段内存缓冲区，用来存储读出的内容 count是我们要读取的字节数 返回值ssize_t类型是linux内核用typedef重定义的一个类型（其实就是int），返回值表示成功读取的字节数。   3.1.3.4、向文件中写入 (1)写入用write系统调用，write的原型和理解方法和read相似 (2)注意const在buf前面的作用，结合C语言高级专题中的输入型参数和输出型参数一节来理解。 (3)注意buf的指针类型为void，结合C语言高级专题中void类型含义的讲解 (4)刚才先写入12字节，然后读出结果读出是0（但是读出成功了），这个问题的答案后面章节会讲，大家先思考一下。     3.1.4.open函数的flag详解1 3.1.4.1、读写权限：O_RDONLY O_WRONLY O_RDWR (1)linux中文件有读写权限，我们在open打开文件时也可以附带一定的权限说明 O_RDONLY 表示以只读方式打开， O_WRONLY 表示以只写方式打开， O_RDWR 表示以可读可写方式打开 (2)当我们附带了权限后，打开的文件就只能按照这种权限来操作。   3.1.4.2、打开存在并有内容的文件时： (1)思考一个问题：当我们打开一个已经存在并且内部有内容的文件时会怎么样？ 可能结果1：先清空文件内容，再写新内容 可能结果2：新内容添加在前面，原来的内容继续在后面 可能结果3：新内容附加在后面，原来的内容还在前面，一般这种情况不存在 可能结果4：将需要写入的内容，在原来的文件中的内容一个一个的覆盖原来的内容 O_TRUNC： 打开文件时，如果这个文件中本来是有内容的，则原来的内容会被丢弃。这就对应上面的结果1 O_APPEND 去打开文件时，如果这个文件中本来是有内容的，则新写入的内容会接续到原来内容的后面，对应结果3 默认 不使用O_APPEND和O_TRUNC属性时就是结果4 O_APPEND | O_TRUNC ? 如果O_APPEND和O_TRUNC同时出现会怎么样？ O_TRUNC 覆盖 O_APPEND 3.1.4.3、exit、_exit、_Exit退出进程 (1)当我们程序在前面步骤操作失败导致后面的操作都没有可能进行下去时，应该在前面的错误监测中结束整个程序，不应该继续让程序运行下去了。 (2)我们如何退出程序？ 第一种；在main用return，一般原则是程序正常终止return 0，如果程序异常终止则return -1。 第一种：正式终止进程（程序）应该使用exit或者_exit或者_Exit之一。   https://wenku.baidu.com/view/4e999b886529647d27285291.html?from=search 3.1.5.open函数的flag详解2 3.1.5.1、打开不存在的文件时：O_CREAT、O_EXCL 当我们open打开一个文件时如果这个文件名不存在则会打开文件错误。 O_CREAT open中加入O_CREAT后，不管原来这个文件存在与否都能打开成功， 如果原来这个文件不存在则创建一个空的新文件， 如果原来这个文件存在则不会有什么影响，和普通打开方式一样 O_CREAT | O_EXCL 如果原来这个文件不存在则创建一个空的新文件， 如果原来这个文件存在则会报错   open("a.txt", O_RDWR | O_CREAT, 0666) 这个数字是8进制 open函数在使用O_CREAT标志去创建文件时，可以使用第三个参数mode来指定要创建的文件的权限。mode使用4个数字来指定权限的，其中后面三个很重要，对应我们要创建的这个文件的权限标志。譬如一般创建一个可读可写不可执行的文件就用0666   3.1.5.2、O_NONBLOCK O_NONBLOCK 非阻塞 默认 阻塞 如果一个函数是阻塞式的，则我们调用这个函数时当前进程有可能被卡住（阻塞住，实质是这个函数内部要完成的事情条件不具备，当前没法做，要等待条件成熟），函数被阻塞住了就不能立刻返回；   如果一个函数是非阻塞式的那么我们调用这个函数后一定会立即返回，但是函数有没有完成任务不一定。   (2)阻塞和非阻塞是两种不同的设计思路，并没有好坏。 总的来说， 阻塞式的 结果有保障 但是 时间没保障 非阻塞式的 时间有保障 但是 结果没保障   (3)操作系统提供的API和由API封装而成的库函数，有很多本身就是被设计为阻塞式或者非阻塞式的，所以我们应用程度调用这些函数的时候心里得非常清楚。   (4)我们打开一个文件默认就是阻塞式的，如果你希望以非阻塞的方式打开文件，则flag中要加O_NONBLOCK标志。   (2)只用于设备文件，而不用于普通文件。   3.1.5.3、O_SYNC 不要等待，直接写到硬盘 (1)write阻塞等待底层完成写入才返回到应用层。 (2)无O_SYNC时write只是将内容写入底层缓冲区即可返回，然后底层（操作系统中负责实现open、write这些操作的那些代码，也包含OS中读写硬盘等底层硬件的代码）在合适的时候会将buf中的内容一次性的同步到硬盘中。 这种设计是为了提升硬件操作的性能和销量，提升硬件寿命；但是有时候我们希望硬件不要等待，直接将我们的内容写入硬盘中，这时候就可以用O_SYNC标志。     3.1.6.文件读写的一些细节 3.1.6.1、errno和perror (1)errno就是error number，意思就是错误号码。linux系统中对各种常见错误做了个编号，当函数执行错误时，函数会返回一个特定的errno编号来告诉我们这个函数到底哪里错了。 (2)errno是由OS来维护的一个全局变量，任何OS内部函数都可以通过设置errno来告诉上层调用者究竟刚才发生了一个什么错误。 (3)errno本身实质是一个int类型的数字，每个数字编号对应一种错误。当我们只看errno时只能得到一个错误编号数字（譬如-37），不适应于人看。 (4)linux系统提供了一个函数perror（意思print error），perror函数内部会读取errno并且将这个不好认的数字直接给转成对应的错误信息字符串，然后print打印出来。   3.1.6.2、read和write的count (1)count和返回值的关系。count参数表示我们想要写或者读的字节数，返回值表示实际完成的要写或者读的字节数。实现的有可能等于想要读写的，也有可能小于（说明没完成任务） (2)count再和阻塞非阻塞结合起来，就会更加复杂。如果一个函数是阻塞式的，则我们要读取30个，结果暂时只有20个时就会被阻塞住，等待剩余的10个可以读。 我觉得这里有错： 因为：我们默认打开的就是阻塞的，但是那么多次实验，我们都是读20个，实际只有5，但还是读出来了，没有等待那15写入 (3)有时候我们写正式程序时，我们要读取或者写入的是一个很庞大的文件（譬如文件有2MB），我们不可能把count设置为2*1024*1024，而应该去把count设置为一个合适的数字（譬如2048、4096），然后通过多次读取来实现全部读完。   3.1.6.3、文件IO效率和标准IO (1)文件IO就指的是我们当前在讲的open、close、write、read等API函数构成的一套用来读写文件的体系，这套体系可以很好的完成文件读写，但是效率并不是最高的。 为了解决这个效率，就在应用层建立一个buff (2)应用层C语言库函数提供了一些用来做文件读写的函数列表，叫标准IO。标准IO由一系列的C库函数构成（fopen、fclose、fwrite、fread），这些标准IO函数其实是由文件IO封装而来的（fopen内部其实调用的还是open，fwrite内部还是通过write来完成文件写入的）。标准IO加了封装之后主要是为了在应用层添加一个缓冲机制，这样我们通过fwrite写入的内容不是直接进入内核中的buf，而是先进入应用层标准IO库自己维护的buf中，然后标准IO库自己根据操作系统单次write的最佳count来选择好的时机来完成write到内核中的buf（内核中的buf再根据硬盘的特性来选择好的实际去最终写入硬盘中）。     3.1.7.linux系统如何管理文件 3.1.7.1、硬盘中的静态文件和inode（i节点） (1)文件平时都在存放在硬盘中的，硬盘中存储的文件以一种固定的形式存放的，我们叫静态文件。 (2)一块硬盘中可以分为两大区域： 一个是硬盘内容管理表项 一个是真正存储内容的区域 操作系统访问硬盘时是先去读取硬盘内容管理表，从中找到我们要访问的那个文件的扇区级别的信息，然后再用这个信息去查询真正存储内容的区域，最后得到我们要的文件。   (3)操作系统最初拿到的信息是文件名，最终得到的是文件内容。 第一步就是去查询硬盘内容管理表，这个管理表中以文件为单位记录了各个文件的各种信息，每一个文件有一个信息列表（我们叫inode，i节点，其实质是一个结构体，这个结构体有很多元素，每个元素记录了这个文件的一些信息，其中就包括文件名、文件在硬盘上对应的扇区号、块号那些东西·····） 强调：硬盘管理的时候是以文件为单位的，每个文件一个inode，每个inode有一个数字编号，对应一个结构体，结构体中记录了各种信息。 (4)联系平时实践，大家格式化硬盘（U盘）时发现有：快速格式化和底层格式化。快速格式化非常快，格式化一个32GB的U盘只要1秒钟，普通格式化格式化速度慢。这两个的差异？其实快速格式化就是只删除了U盘中的硬盘内容管理表（其实就是inode），真正存储的内容没有动。这种格式化的内容是有可能被找回的。   3.1.7.2、内存中被打开的文件和vnode（v节点） (1)一个程序的运行就是一个进程，我们在程序中打开的文件就属于某个进程。 每个进程都有一个数据结构用来记录这个进程的所有信息（叫进程信息表），表中有一个指针会指向一个文件管理表，文件管理表中记录了当前进程打开的所有文件及其相关信息。 文件管理表中用来索引各个打开的文件的index就是文件描述符fd，我们最终找到的就是一个已经被打开的文件的管理结构体vnode   (2)一个vnode中就记录了一个被打开的文件的各种信息，而且我们只要知道这个文件的fd，就可以很容易的找到这个文件的vnode进而对这个文件进行各种操作。 一个表项就是一个vnode，表项的编号就是fd vnode用于内存表示，Inode用于硬盘表示 3.1.7.3、文件与流的概念 (1)流（stream）对应自然界的水流。文件操作中，文件类似是一个大包裹，里面装了一堆字符，但是文件被读出/写入时都只能一个字符一个字符的进行，而不能一股脑儿的读写，那么一个文件中N多的个字符被挨个一次读出/写入时，这些字符就构成了一个字符流。 (2)流这个概念是动态的，不是静态的。 (3)编程中提到流这个概念，一般都是IO相关的。所以经常叫IO流。文件操作时就构成了一个IO流。     3.1.8.lseek详解 3.1.8.1、lseek函数介绍 off_t lseek( int fd, off_t offset, int whence); whence： SEEK_SET The offset is set to offset bytes. SEEK_CUR The offset is set to its current location plus offset bytes. SEEK_END The offset is set to the size of the file plus offset bytes. off_t offset：偏移量 返回值：文件指针的位置 (1)文件指针：我认为叫文件内部指针更好 当我们要对一个文件进行读写时，一定需要先打开这个文件，所以我们读写的所有文件都是动态文件。动态文件在内存中的形态就是文件流的形式。   (2)文件流很长，里面有很多个字节。那我们当前正在操作的是哪个位置？GUI模式下的软件用光标来标识这个当前正在操作的位置，这是给人看的。   (3)在动态文件中，我们会通过文件指针来表征这个正在操作的位置。所谓文件指针，就是我们文件管理表这个结构体里面的一个指针。所以文件指针其实是vnode中的一个元素。这个指针表示当前我们正在操作文件流的哪个位置。这个指针不能被直接访问，linux系统用lseek函数来访问这个文件指针。   (4)当我们打开一个空文件时，默认情况下文件指针指向文件流的开始。所以这时候去write时写入就是从文件开头开始的。write和read函数本身自带移动文件指针的功能，所以当我write了n个字节后，文件指针会自动向后移动n位。如果需要人为的随意更改文件指针，那就只能通过lseek函数了   (5)read和write函数都是从当前文件指针处开始操作的，所以当我们用lseek显式的将文件指针移动后，那么再去read/write时就是从移动过后的位置开始的。   (6)回顾前面一节中我们从空文件，先write写了12字节，然后read时是空的（但是此时我们打开文件后发现12字节确实写进来了）。   3.1.8.2、用lseek计算文件长度 (1)linux中并没有一个函数可以直接返回一个文件的长度。但是我们做项目时经常会需要知道一个文件的长度，怎么办？自己利用lseek来写一个函数得到文件长度即可。 ret = lseek( fd, 0, SEEK_END);   3.1.8.3、用lseek构建空洞文件 (1)空洞文件就是这个文件中有一段是空的。 空洞的那一段用乱码表示：   (2)普通文件中间是不能有空的，因为我们write时文件指针是依次从前到后去移动的，不可能绕过前面直接到后面。 (3)我们打开一个文件后，用lseek往后跳过一段，再write写入一段，就会构成一个空洞文件。 (4)空洞文件方法对多线程共同操作文件是及其有用的。有时候我们创建一个很大的文件，如果从头开始依次构建时间很长。有一种思路就是将文件分为多段，然后多线程来操作每个线程负责其中一段的写入。 空洞文件有什么用？ 空洞文件作用很大，例如迅雷下载文件，在未下载完成时就已经占据了全部文件大小的空间，这时候就是空洞文件。下载时如果没有空洞文件，多线程下载时文件就都只能从头一点一点写入，这就不是多线程了。如果有了空洞文件，可以从不同的地址写入，就完成了多线程的优势任务。   3.1.9.多次打开同一文件与O_APPEND 3.1.9.1、重复打开同一文件读取 (1)一个进程中两次打开同一个文件，然后分别读取，看结果会怎么样 (2)结果无非2种情况：一种是fd1和fd2分别读，第二种是接续读。经过实验验证，证明了结果是fd1和fd2分别读。 (3)分别读说明：我们使用open两次打开同一个文件时，fd1和fd2所对应的文件指针是不同的2个独立的指针。文件指针是包含在动态文件的文件管理表中的，所以可以看出linux系统的进程中不同fd对应的是不同的独立的文件管理表。   3.1.9.2、重复打开同一文件写入 (1)一个进程中2个打开同一个文件，得到fd1和fd2.然后看是分别写还是接续写？ (2)正常情况下我们有时候需要分别写，有时候又需要接续写，所以这两种本身是没有好坏之分的。关键看用户需求 (3)默认情况下应该是：分别写（实验验证过的）   3.1.9.3、加O_APPEND解决覆盖问题 (1)有时候我们希望接续写而不是分别写？办法就是在open时加O_APPEND标志即可 分别写ab cd   3.1.9.4、O_APPEND的实现原理和其原子操作性说明 (1)O_APPEND为什么能够将分别写改为接续写？关键的核心的东西是文件指针。 分别写的内部原理就是2个fd拥有不同的文件指针，并且彼此只考虑自己的位移。 但是O_APPEND标志可以让write和read函数内部多做一件事情，就是移动自己的文件指针的同时也去把别人的文件指针同时移动。（也就是说即使加了O_APPEND，fd1和fd2还是各自拥有一个独立的文件指针，但是这两个文件指针关联起来了，一个动了会通知另一个跟着动） 加O_APPEND的效果和dup(),dup2()相同   (2)O_APPEND对文件指针的影响，对文件的读写是原子的。   (3)原子操作的含义是：整个操作一旦开始是不会被其他进程打断的，必须直到该进程操作结束， 其他进程才能得以调度运行，这就叫原子操作。每种操作系统中都有一些机制来实现原子操作，以保证那些需要原子操作的任务可以运行。     3.1.10.文件共享的实现方式 3.1.10.1、什么是文件共享 (1)文件共享就是同一个文件（同一个文件指的是同一个inode，同一个pathname）被多个独立的读写体（几乎可以理解为多个文件描述符）去同时（一个打开尚未关闭的同时另一个去操作）操作。 文件共享的意义： 1.譬如我们可以通过文件共享来实现多线程同时操作同一个大文件，以减少文件读写时间，提升效率。 2.可以实现进程间通信 3.1.10.2、文件共享的3种实现方式 (1)文件共享的核心就是怎么弄出来多个文件描述符指向同一个文件。 (2)常见的有3种文件共享的情况： 第一种是同一个进程中多次使用open打开同一个文件，     第二种是在不同进程中去分别使用open打开同一个文件（这时候因为两个fd在不同的进程中，所以两个fd的数字可以相同也可以不同），   第三种情况是后面要学的，linux系统提供了dup和dup2两个API来让进程复制文件描述符。   第四种：在一个进程中，直接指定文件描述符，这种结果和第三种一样，就是接续写 fd1 = open(FILENAME, O_RDWR); fd2 = fd1;   (3)我们分析文件共享时的核心关注点在于：分别写/读还是接续写/读   3.1.10.3、再论文件描述符 (1)文件描述符的本质是一个数字，这个数字本质上是进程表中文件描述符表的一个表项，进程通过文件描述符作为index去索引查表得到文件表指针，再间接访问得到这个文件对应的文件表。   (2)文件描述符这个数字是open系统调用内部由操作系统自动分配的，操作系统分配这个fd时也不是随意分配，也是遵照一定的规律的，我们现在就要研究这个规律。   (3)操作系统规定，fd从0开始依次增加。fd也是有最大限制的，在linux的早期版本中（0.11）fd最大是20，所以当时一个进程最多允许打开20个文件。linux中文件描述符表是个数组（不是链表），所以这个文件描述符表其实就是一个数组，fd是index，文件表指针是value   (4)当我们去open时，内核会从文件描述符表中挑选一个最小的未被使用的数字给我们返回。也就是说如果之前fd已经占满了0-9，那么我们下次open得到的一定是10.（但是如果上一个fd得到的是9，下一个不一定是10，这是因为可能前面更小的一个fd已经被close释放掉了）   (5)fd中0、1、2已经默认被系统占用了，因此用户进程得到的最小的fd就是3了。   (6)linux内核占用了0、1、2这三个fd是有用的，当我们运行一个程序得到一个进程时，内部就默认已经打开了3个文件，这三个文件对应的fd就是0、1、2。这三个文件分别叫stdin、stdout、stderr。也就是标准输入、标准输出、标准错误。   (7)标准输入一般对应的是键盘（可以理解为：0这个fd对应的是键盘的设备文件），标准输出一般是LCD显示器（可以理解为：1对应LCD的设备文件） 实验验证：close(1)后直接界面不输出了 但是close(1) 这句代码以后的程序 的 输出内容 会输入到 新打开的文件中，这个文件的描述符为1 (8)printf函数其实就是默认输出到标准输出stdout上了。stdio中还有一个函数叫fpirntf，这个函数就可以指定输出到哪个文件描述符中。 文件描述符与文件指针的区别 https://blog.csdn.net/qq_40732350/article/details/81946297   3.1.11.文件描述符的复制1 3.1.11.1、dup和dup2函数介绍   3.1.11.2、使用dup进行文件描述符复制 (1)dup系统调用对fd进行复制，会返回一个新的文件描述符（譬如原来的fd是3，返回的就是4） (2)dup系统调用有一个特点，就是自己不能指定复制后得到的fd的数字是多少，而是由操作系统内部自动分配的，分配的原则遵守fd分配的原则。 (3)dup返回的fd和原来的oldfd都指向oldfd打开的那个动态文件，操作这两个fd实际操作的都是oldfd打开的那个文件。实际上构成了文件共享。 (4)dup返回的fd和原来的oldfd同时向一个文件写入时，结果是分别写还是接续写？   3.1.11.3、使用dup的缺陷分析 (1)dup并不能指定分配的新的文件描述符的数字，dup2系统调用修复了这个缺陷，所以平时项目中实际使用时根据具体情况来决定用dup还是dup2. 3.1.11.4、练习 (1)之前课程讲过0、1、2这三个fd被标准输入、输出、错误通道占用。而且我们可以关闭这三个 (2)我们可以close(1)关闭标准输出，关闭后我们printf输出到标准输出的内容就看不到了 (3)然后我们可以使用dup重新分配得到1这个fd，这时候就把oldfd打开的这个文件和我们1这个标准输出通道给绑定起来了。这就叫标准输出的重定位。 (4)可以看出，我们可以使用close和dup配合进行文件的重定位。     3.1.12.文件描述符的复制2 3.1.12.1、使用dup2进行文件描述符复制 (1)dup2和dup的作用是一样的，都是复制一个新的文件描述符。但是dup2允许用户指定新的文件描述符的数字。 (2)使用方法看man手册函数原型即可。   3.1.12.2、dup2共享文件交叉写入测试 (1)dup2复制的文件描述符，和原来的文件描述符虽然数字不一样，但是这连个指向同一个打开的文件 (2)交叉写入的时候，结果是接续写（实验证明的）。   3.1.12.3、命令行中重定位命令 > (1)linux中的shell命令执行后，打印结果都是默认进入stdout的（本质上是因为这些命令譬如ls、pwd等都是调用printf进行打印的），所以我们可以在linux的终端shell中直接看到命令执行的结果。 (2)能否想办法把ls、pwd等命令的输出给重定位到一个文件中（譬如2.txt）去，实际上linux终端支持一个重定位的符号>很简单可以做到这点。 (3)这个>的实现原理，其实就是利用open+close+dup， open打开一个文件2.txt，得到文件描述符4（假设） 然后close关闭stdout，文件描述符1就会空着 然后fd2 = dup(4) 着就会将1和2.txt文件关联起来即可。   文件锁：   3.1.13.fcntl函数介绍 3.1.13.1、fcntl的原型和作用 (1)fcntl函数是一个多功能文件管理的工具箱，接收2个参数+1个变参。 第一个参数是fd表示要操作哪个文件， 第二个参数是cmd表示要进行哪个命令操作。 变参是用来传递参数的，要配合cmd来使用。 (2)cmd的样子类似于F_XXX，不同的cmd具有不同的功能。学习时没必要去把所有的cmd的含义都弄清楚（也记不住），只需要弄明白一个作为案例，搞清楚它怎么看怎么用就行了，其他的是类似的。其他的当我们在使用中碰到了一个fcntl的不认识的cmd时再去查man手册即可。   3.1.13.2、fcntl的常用cmd (1)F_DUPFD这个cmd的作用是复制文件描述符（作用类似于dup和dup2），这个命令的功能是从可用的fd数字列表中找一个比arg大或者和arg一样大的数字作为oldfd的一个复制的fd，和dup2有点像但是不同。dup2返回的就是我们指定的那个newfd否则就会出错，但是F_DUPFD命令返回的是>=arg的最小的那一个数字。   3.1.13.3、使用fcntl模拟dup2     3.1.14.标准IO库介绍 3.1.14.1、标准IO和文件IO有什么区别 (1)看起来使用时都是函数，但是：标准IO是C库函数，而文件IO是linux系统的API (2)C语言库函数是由API封装而来的。库函数内部也是通过调用API来完成操作的，但是库函数因为多了一层封装，所以比API要更加好用一些。 (3)库函数比API还有一个优势就是：API在不同的操作系统之间是不能通用的，但是C库函数在不同操作系统中几乎是一样的。所以C库函数具有可移植性而API不具有可移植性。 (4)性能上和易用性上看，C库函数一般要好一些。譬如IO，文件IO是不带缓存的，而标准IO是带缓存的，因此标准IO比文件IO性能要更高。   3.1.14.2、常用标准IO函数介绍 (1)常见的标准IO库函数有：fopen、fclose、fwrite、fread、ffulsh、fseek   3.1.14.3、一个简单的标准IO读写文件实例