当前位置 博文首页 > lyndon_li的博客：刨根问底（一）由 Linux 输入流引发的思考
cat, more, less, head, tail, cut, sort, wc, sed …
ls, pwd, cd …
输入流就是标准输入，在 C 程序里习惯记为 STDIN_FILENO。
/* Standard file descriptors. */
#define STDIN_FILENO 0 /* Standard input. */
#define STDOUT_FILENO 1 /* Standard output. */
#define STDERR_FILENO 2 /* Standard error output. */
命令还有这区别？平时没怎么注意过。什么叫做支持输入流，什么叫做不支持输入流呢？答案就是这个命令能不能够从标准输入读取数据，能就是支持输入流，不能就是不支持输入流。
例如：
支持输入流：cat
$ cat
hello
hello
我们在命令行输入 cat 回车，cat 进程就开始从标准输入读取数据，读不到就阻塞。我们从标准输入（这里是键盘设备）输入 hello 回车，cat 进程就从标准输入读取 hello 并输入到标准输出上（这里是屏幕设备）。
相反，
不支持输入流：ls
$ ls
bin dev lib libx32 mnt root snap sys var
boot etc lib32 lost+found opt run srv tmp
cdrom home lib64 media proc sbin swapfile usr
我们输入 ls 回车，它不会企图从标准输入读入内容。就算我们尝试给它一个输入，如：
$ echo "hello" | ls
bin dev lib libx32 mnt root snap sys var
boot etc lib32 lost+found opt run srv tmp
cdrom home lib64 media proc sbin swapfile usr
ls 也是非常高冷地忽视，不接受标准输入的内容。
cat, ls 差异背后的原理是什么呢？最好的探索办法就是看源码
cat.c 部分代码
FILE *bb_wfopen_input(const char *filename)
{
FILE *fp = stdin;
if ((filename != bb_msg_standard_input)
&& filename[0] && ((filename[0] != '-') || filename[1])
) {
#if 0
/* This check shouldn't be necessary for linux, but is left
* here disabled just in case. */
struct stat stat_buf;
if (is_directory(filename, 1, &stat_buf)) {
bb_error_msg("%s: Is a directory", filename);
return NULL;
}
#endif
fp = bb_wfopen(filename, "r");
}
return fp;
}
可以看到，cat 先判断有没有输入文件名，输入了就打开此文件，没输入文件名就默认打开标准输入。这就是为什么我们在命令行输入 cat 直接回车，cat 会从标准输入读取内容的原因了。
再来看 ls.c
extern int ls_main(int argc, char **argv)
{
ac = argc - optind; /* how many cmd line args are left */
if (ac < 1) {
av = (char **) xcalloc((size_t) 1, (size_t) (sizeof(char *)));
av[0] = bb_xstrdup(".");
ac = 1;
} else {
av = (char **) xcalloc((size_t) ac, (size_t) (sizeof(char *)));
for (oi = 0; oi < ac; oi++) {
av[oi] = argv[optind++]; /* copy pointer to real cmd line arg */
}
}
/* now, everything is in the av array */
if (ac > 1)
all_fmt |= DISP_DIRNAME; /* 2 or more items? label directories */
/* stuff the command line file names into an dnode array */
dn = NULL;
for (oi = 0; oi < ac; oi++) {
char *fullname = bb_xstrdup(av[oi]);
cur = my_stat(fullname, fullname);
if (!cur)
continue;
cur->next = dn;
dn = cur;
nfiles++;
}
...
}
ls 只处理了命令行参数，并没有读取标准输入。
至此，命令支不支持输入流的问题已小有结论。就看它有没有去处理 stdin。
又有个疑问冒出来了：进程的 标准输入、标准输出、标准错误 哪来的？
write(1, "test\n", sizeof("test\n"));
为什么这行代码就能向标准输出打印 test ？标准输出 “1” 来自于哪里？
按惯例，每当运行一个新程序时，所有的 shell 都为其打开三个文件描述符：标准输入(standard input)、标准输出(standard output) 以及标准错误(standard error)。如果像简单命令 ls 那样没有做什么特殊处理，则这三个描述符都链向终端。
—— 《UNIX 环境高级编程 第3版》
所以说，进程的 标准输入、标准输出、标准错误 来自于 shell。
那 shell 是怎么把 标准输入、标准输出、标准错误 给到进程的呢？shell 自身的 标准输入、标准输出、标准错误 又是源自于哪里呢？
回答上面两个问题前，我们先了解以下 shell 的基本实施，请参考 《35 行代码实现一个简单的 shell》
对于问题一，我的理解：
子进程（我们在 shell 中运行的用户程序）是被 shell fork() + execlp() 出来的。在 fork 过程中，子进程获得了和父进程一模一样的资源，其中就包括 标准输入、标准输出、标准错误 。而 execlp 只是替换进程，进程所处的环境没有变，所以 execlp 替换的新进程依然享有被替换的程序所拥有的 标准输入、标准输出、标准错误(经过实验验证了：父进程中关掉标准输出，子进程也找不到标准输出了，但是没找到理论依据)。
对于问题二，我的理解：
shell 进程是被 1 号祖先进程 init 克隆出来的，自然能够从 init 进程获取 标准输入、标准输出、标准错误；而 init 进程又是从 kernel 中获取到它们的。
以下就是我目前的理解框图：
0.7
欢迎大家讨论并指正
