在我作为C程序员的几年中,我一直对标准stream文件描述符感到困惑。 一些地方,如维基百科[1] ,说:
在C编程语言中,标准input,输出和错误stream分别附加到现有的Unix文件描述符0,1和2上。
这是由unistd.h
备份的:
/* Standard file descriptors. */ #define STDIN_FILENO 0 /* Standard input. */ #define STDOUT_FILENO 1 /* Standard output. */ #define STDERR_FILENO 2 /* Standard error output. */
但是,这个代码(在任何系统上):
write(0, "Hello, World!\n", 14);
将打印Hello, World!
(和一个换行符)到STDOUT
。 这很奇怪,因为STDOUT
的文件描述符应该是1. write
文件描述符1也打印到STDOUT
。
在文件描述符0上执行ioctl
更改标准input[2] ,并在文件描述符1上更改标准输出。 但是,在0或1上执行termios
函数会改变标准input[3] [4] 。
我对文件描述符1和0的行为非常困惑。有谁知道为什么:
write
1或0写入标准输出? ioctl
on 1会修改标准输出,并在0上修改标准input,但在1或0上执行tcsetattr
/ tcgetattr
可用于标准input? 首先回顾一下所涉及的一些关键概念:
文件描述
在操作系统内核中,每个文件,管道端点,套接字端点,打开的设备节点等都有一个文件描述 。 内核使用这些来跟踪文件中的位置,标志(读,写,附加,关闭执行),记录锁等等。
文件描述是内核的内核,不属于任何特定的进程(在典型的实现中)。
文件描述符
从处理的角度来看,文件描述符是识别打开的文件,管道,套接字,FIFO或设备的整数。
操作系统内核为每个进程保留一个描述符表。 进程使用的文件描述符只是该表的索引。
文件描述符表中的条目是指内核文件描述。
每当进程使用dup()
或dup2()
复制文件描述符时,内核只复制该进程的文件描述符表中的条目; 它不重复它自己保存的文件描述。
当进程分叉时,子进程获取自己的文件描述符表,但是这些条目仍指向完全相同的内核文件描述。 (这实质上是一个浅拷贝 ,所有的文件描述符表项都是文件描述的引用,引用被复制;引用的目标保持不变。
当进程通过Unix域套接字辅助消息将文件描述符发送到另一个进程时,内核实际上在接收器上分配一个新的描述符,并复制所传送的描述符引用的文件描述。
尽管“文件描述符”和“文件描述”如此相似,但有点令人困惑,这一切都运行良好。
所有这些与OP看到的效果有什么关系?
每当创建新进程时,通常会打开目标设备,管道或套接字,并将描述符dup2()
打开为标准输入,标准输出和标准错误。 这导致所有三个标准描述符引用相同的文件描述 ,因此无论使用一个文件描述符有效的操作,使用其他文件描述符也是有效的。
当在控制台上运行程序时这是最常见的,因为这三个描述符都明确地指向相同的文件描述; 该文件描述描述了伪终端字符设备的从端。
考虑下面的程序run.c :
#define _POSIX_C_SOURCE 200809L #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h> #include <errno.h> static void wrerrp(const char *p, const char *q) { while (p < q) { ssize_t n = write(STDERR_FILENO, p, (size_t)(q - p)); if (n > 0) p += n; else return; } } static inline void wrerr(const char *s) { if (s) wrerrp(s, s + strlen(s)); } int main(int argc, char *argv[]) { int fd; if (argc < 3) { wrerr("\nUsage: "); wrerr(argv[0]); wrerr(" FILE-OR-DEVICE COMMAND [ ARGS ... ]\n\n"); return 127; } fd = open(argv[1], O_RDWR | O_CREAT, 0666); if (fd == -1) { const char *msg = strerror(errno); wrerr(argv[1]); wrerr(": Cannot open file: "); wrerr(msg); wrerr(".\n"); return 127; } if (dup2(fd, STDIN_FILENO) != STDIN_FILENO || dup2(fd, STDOUT_FILENO) != STDOUT_FILENO) { const char *msg = strerror(errno); wrerr("Cannot duplicate file descriptors: "); wrerr(msg); wrerr(".\n"); return 126; } if (dup2(fd, STDERR_FILENO) != STDERR_FILENO) { /* We might not have standard error anymore.. */ return 126; } /* Close fd, since it is no longer needed. */ if (fd != STDIN_FILENO && fd != STDOUT_FILENO && fd != STDERR_FILENO) close(fd); /* Execute the command. */ if (strchr(argv[2], '/')) execv(argv[2], argv + 2); /* Command has /, so it is a path */ else execvp(argv[2], argv + 2); /* command has no /, so it is a filename */ /* Whoops; failed. But we have no stderr left.. */ return 125; }
它需要两个或更多的参数。 第一个参数是文件或设备,第二个参数是命令,剩下的参数提供给命令。 运行该命令,将所有三个标准描述符重定向到第一个参数中指定的文件或设备。 你可以用gcc编译上面的例子
gcc -Wall -O2 run.c -o run
我们来写一个小测试工具report.c :
#define _POSIX_C_SOURCE 200809L #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h> #include <stdio.h> #include <errno.h> int main(int argc, char *argv[]) { char buffer[16] = { "\n" }; ssize_t result; FILE *out; if (argc != 2) { fprintf(stderr, "\nUsage: %s FILENAME\n\n", argv[0]); return EXIT_FAILURE; } out = fopen(argv[1], "w"); if (!out) return EXIT_FAILURE; result = write(STDIN_FILENO, buffer, 1); if (result == -1) { const int err = errno; fprintf(out, "write(STDIN_FILENO, buffer, 1) = -1, errno = %d (%s).\n", err, strerror(err)); } else { fprintf(out, "write(STDIN_FILENO, buffer, 1) = %zd%s\n", result, (result == 1) ? ", success" : ""); } result = read(STDOUT_FILENO, buffer, 1); if (result == -1) { const int err = errno; fprintf(out, "read(STDOUT_FILENO, buffer, 1) = -1, errno = %d (%s).\n", err, strerror(err)); } else { fprintf(out, "read(STDOUT_FILENO, buffer, 1) = %zd%s\n", result, (result == 1) ? ", success" : ""); } result = read(STDERR_FILENO, buffer, 1); if (result == -1) { const int err = errno; fprintf(out, "read(STDERR_FILENO, buffer, 1) = -1, errno = %d (%s).\n", err, strerror(err)); } else { fprintf(out, "read(STDERR_FILENO, buffer, 1) = %zd%s\n", result, (result == 1) ? ", success" : ""); } if (ferror(out)) return EXIT_FAILURE; if (fclose(out)) return EXIT_FAILURE; return EXIT_SUCCESS; }
它只需要一个参数,一个文件或设备写入,报告是否写入标准输入,以及读取标准输出和错误工作。 (我们通常可以在Bash和POSIX shell中使用$(tty)
来引用实际的终端设备,这样报表就可以在终端上看到了。)用eg编译这个
gcc -Wall -O2 report.c -o report
现在,我们可以检查一些设备:
./run /dev/null ./report $(tty) ./run /dev/zero ./report $(tty) ./run /dev/urandom ./report $(tty)
或任何我们想要的。 在我的机器上,当我在一个文件上运行这个,说
./run some-file ./report $(tty)
写入标准输入,并从标准输出和标准错误读取所有工作 – 这是预期的,因为文件描述符指的是相同的,可读和可写的文件描述。
玩完这个之后,结论就是这里根本没有什么奇怪的行为 。 如果进程使用的文件描述符只是对操作系统内部文件描述的引用,并且标准输入,输出和错误描述符是相互重复的,则它们的行为与期望的完全相同。
我想这是因为在我的Linux中,默认情况下, 0
和1
都是通过读/写打开/dev/tty
进程的控制终端。 所以甚至可以从stdout
读取 。
然而,只要你把东西输入或输出,
#include <unistd.h> #include <errno.h> #include <stdio.h> int main() { errno = 0; write(0, "Hello world!\n", 14); perror("write"); }
和运行
% ./a.out Hello world! write: Success % echo | ./a.out write: Bad file descriptor
termios
函数总是在实际的底层终端对象上工作,所以只要打开一个tty, 0
或1
是否被使用并不重要。