一、STDIN_FILENO 与stdin的区别
STDIN_FILENO 与stdin的区别_wangzhen_csdn的博客-CSDN博客_stdin类型
1.STDIN_FILENO的作用
STDIN_FILENO属于系统API接口库，其声明为 int 型，是一个打开文件句柄，对应的函数主要包括 open/read/write/close 等系统级调用。
操作系统一级提供的文件API都是以文件描述符来表示文件。STDIN_FILENO就是标准输入设备（一般是键盘）的文件描述符。
例：(一次一个字节地从标准输入拷贝到标准输出)
#include"csapp.h"
int main(void)
{
char c;
while(Read(STDIN_FILENO,&c, 1)!= 0)
Write(STDOUT_FILENO,&c, 1);
exit( 0);
}STDIN_FILENO→→&c(存储器位置)→→STDOUT_FILENO
2.区别
1）数据类型不一致：
stdin类型为 FILE*
STDIN_FILENO类型为 int
使用stdin的函数主要有：fread、fwrite、fclose等，基本上都以f开头
使用STDIN_FILENO的函数有：read、write、close等
2）IO类型不一致：
stdin等是FILE *类型，属于标准I/O，高级的输入输出函数。在<stdio.h>。
STDIN_FILENO等是文件描述符，是非负整数，一般定义为0, 1, 2，属于没有buffer的I/O，直接调用系统调用，在<unistd.h>。
3）STDIN_FILENO 是标准输入的文件描述符
详见 /usr/include/unistd.h
代码:
/* Standard file descriptors. */
#define STDIN_FILENO 0 /* Standard input. */
#define STDOUT_FILENO 1 /* Standard output. */
#define STDERR_FILENO 2 /* Standard error output. */
4）层次不一样。
stdin属于标准库处理的输入流，其声明为 FILE *型的，对应的函数前面都有f开头，如fopen/fread/fwrite/fclose 标准库调用等
STDIN_FILENO属于系统API接口库，其声明为 int 型，是一个打开文件句柄，对应的函数主要包括 open/read/write/close 等系统级调用。
标准库内封装了系统 API 调用，如 fread 内部实现调用 read。
5）其它
操作系统一级提供的文件API都是以文件描述符来表示文件。STDIN_FILENO就是标准输入设备（一般是键盘）的文件描述符。
为什么一个整形fd（STDIN_FILENO=0）就可以代表一个打开的文件呢？
和我们的手机号是类似的，手机号只是一个9位数的整形，但是在移动通话网络里，它就可以用来区分不同的手机终端。
标准C++一级提供的文件操作函数库都是用FILE*来表示文件，stdin就是指向标准输入设备文件的FILE*
二、cc、gcc 与g++的区别
1、cc与gcc
首先，如果讨论范围在Unix和Linux之间，那么cc和gcc不是同一个东西。cc来自于Unix的c语言编译器，是 c compiler 的缩写。gcc来自Linux世界，是GNU compiler collection 的缩写，注意这是一个编译器集合，不仅仅是c或c++。
其次， 如果讨论范围仅限于Linux，我们可以认为它们是一样的，在Linux下调用cc时，其实际上并不指向unix的cc编译器，而是指向了gcc，也就是说cc是gcc的一个链接（快捷方式），看看下面的终端输出就明白了：
[root@localhost linux_c]# which cc
/usr/bin/cc
[root@localhost linux_c]# ls -al /usr/bin/cc
lrwxrwxrwx. 1 root root 3 Mar 31 2021 /usr/bin/cc -> gcc
[root@localhost linux_c]# 为什么会这样，很简单，为了兼容性：
cc是Unix下的，是收费的，可不向Linux那样可以那来随便用，所以Linux下是没有cc的
然后，问题来了，如果我的c/c++项目是在Unix下编写的，在写makefile文件时自然地用了cc，当将其放到Linux下这无法make了，必须将其中的cc全部修改成gcc。这太麻烦了哈，所以，Linux这想了这么一个方便的解决方案：不修改makefile，继续使用cc，这个cc是个“冒牌货”，它实际指向gcc。
2、gcc与g++
我们在编译c/c++代码的时候，有人用gcc，有人用g++，于是各种说法都来了，譬如c代码用gcc，而c++代码用g++，或者说编译用gcc，链 接用g++，一时也不知哪个说法正确，如果再遇上个extern "C"，分歧就更多了，这里我想作个了结，毕竟知识的目的是令人更清醒，而不是更糊涂。
误区一:gcc只能编译c代码,g++只能编译c++代码
两者都可以，但是请注意：
1.后缀为.c的，gcc把它当作是C程序，而g++当作是c++程序；后缀为.cpp的，两者都会认为是c++程序，注意，虽然c++是c的超集，但是两者对语法的要求是有区别的，例如：
#include <stdio.h>
int main(int argc, char* argv[]) {
if(argv == 0) return;
printString(argv);
return;
}
int printString(char* string) {
sprintf(string, "This is a test.\n");
}
如果按照C的语法规则，OK，没问题，但是，一旦把后缀改为cpp，立刻报三个错：“printString未定义”；
“cannot convert `char**' to `char*”；
”return-statement with no value“；
分别对应前面红色标注的部分。可见C++的语法规则更加严谨一些。
2.编译阶段，g++会调用gcc，对于c++代码，两者是等价的，但是因为gcc命令不能自动和C＋＋程序使用的库联接，所以通常用g++来完成链接，为了统一起见，干脆编译/链接统统用g++了，这就给人一种错觉，好像cpp程序只能用g++似的。
误区二:gcc不会定义__cplusplus宏，而g++会
实际上，这个宏只是标志着编译器将会把代码按C还是C++语法来解释，如上所述，如果后缀为.c，并且采用gcc编译器，则该宏就是未定义的，否则，就是已定义。
误区三:编译只能用gcc，链接只能用g++
严格来说，这句话不算错误，但是它混淆了概念，应该这样说：编译可以用gcc/g++，而链接可以用g++或者gcc -lstdc++。因为gcc命令不能自动和C＋＋程序使用的库联接，所以通常使用g++来完成联接。但在编译阶段，g++会自动调用gcc，二者等价。
误区四:extern "C"与gcc/g++有关系
实际上并无关系，无论是gcc还是g++，用extern "c"时，都是以C的命名方式来为symbol命名，否则，都以c++方式命名。试验如下：
me.h：
extern "C" void CppPrintf(void);
me.cpp:
#include <iostream>
#include "me.h"
using namespace std;
void CppPrintf(void)
{
cout << "Hello\n";
}
test.cpp:
#include <stdlib.h>
#include <stdio.h>
#include "me.h"
int main(void)
{
CppPrintf();
return 0;
}
1. 先给me.h加上extern "C"，看用gcc和g++命名有什么不同
[root@root G++]# g++ -S me.cpp
[root@root G++]# less me.s
.globl _Z9CppPrintfv //注意此函数的命名
.type CppPrintf, @function
[root@root GCC]# gcc -S me.cpp
[root@root GCC]# less me.s
.globl _Z9CppPrintfv //注意此函数的命名
.type CppPrintf, @function
完全相同！
2. 去掉me.h中extern "C"，看用gcc和g++命名有什么不同
[root@root GCC]# gcc -S me.cpp
[root@root GCC]# less me.s
.globl _Z9CppPrintfv //注意此函数的命名
.type _Z9CppPrintfv, @function
[root@root G++]# g++ -S me.cpp
[root@root G++]# less me.s
.globl _Z9CppPrintfv //注意此函数的命名
.type _Z9CppPrintfv, @function
完全相同！
【结论】完全相同，可见extern "C"与采用gcc/g++并无关系，以上的试验还间接的印证了前面的说法：在编译阶段，g++是调用gcc的
三、Linux输入输出重定向
shell中输入输出重定向，＞、＞＞、＜、＜＜、＞/dev/null、2＞&1、＜＜end、＜＜EOF 用法 - 为什么要取名字 - 博客园
在执行shell 命令过程中，经常会用到 >dev/null ,nohup xxx 2>&1 这样的命令，那么这些命令有什么区别呢？
shell重定向介绍
就像我们平时写的程序一样，一段程序会处理外部的输入，然后将运算结果输出到指定的位置。在交互式的程序中，输入来自用户的键盘和鼠标，结果输出到用户的屏幕，。而对于某些后台运行的程序，输入可能来自于外部的一些文件，运算的结果通常又写到其他的文件中。而且程序在运行的过程中，会有一些关键性的信息，比如异常堆栈，外部接口调用情况等，这些都会统统写到日志文件里。
shell脚本也一样，但是我们一般在使用shell命令的时候，更多地还是通过键盘输入，然后在屏幕上查看命令的执行结果。如果某些情况下，我们需要将shell命令的执行结果存储到文件中，那么我们就需要使用输入输出的重定向功能。
文件描述符
当执行shell命令时，会默认打开3个文件，每个文件有对应的文件描述符来方便我们使用：
| 类型 | 文件描述符 | 默认情况 | 对应文件句柄位置 |
|---|---|---|---|
| 标准输入（standard input） | 0 | 从键盘获得输入 | /proc/self/fd/0 |
| 标准输出（standard output） | 1 | 输出到屏幕（即控制台） | /proc/self/fd/1 |
| 错误输出（error output） | 2 | 输出到屏幕（即控制台） | /proc/self/fd/2 |
所以我们平时在执行shell命令中，都默认是从键盘获得输入，并且将结果输出到控制台上。但是我们可以通过更改文件描述符默认的指向，从而实现输入输出的重定向。比如我们将1指向文件，那么标准的输出就会输出到文件中。
输出重定向
输出重定向的使用方式很简单，基本的一些命令如下：
| 命令 | 介绍 |
|---|---|
| command >filename | 把标准输出重定向到新文件中 |
| command 1>filename | 同上 |
| command >>filename | 把标准输出追加到文件中 |
| command 1>>filename | 同上 |
| command 2>filename | 把标准错误重定向到新文件中 |
| command 2>>filename | 把标准错误追加到新文件中 |
1.我们使用>或者>>对输出进行重定向。符号的左边表示文件描述符，如果没有的话表示1，也就是标准输出，符号的右边可以是一个文件，也可以是一个输出设备。
2.当使用>时，会判断右边的文件存不存在，如果存在的话就先删除，然后创建一个新的文件，不存在的话则直接创建。
3.当使用>>进行追加时，则不会删除原来已经存在的文件。
为了更好地理解输出重定向，感受重定向的“魅力”，我们看一下以下的例子：我们创建一个测试目录，目录下面仅有一个a.txt文件。
| 1 2 3 4 5 6 7 |
|
在我们执行ls a.txt b.txt之后，一共有两种输出，其中ls: 无法访问b.txt: 没有那个文件或目录是错误输出，a.txt是标准输出。
| 1 2 3 4 5 6 7 8 9 |
|
在上述命令中，我们将原来的标准输出重定向到了out文件中，所以控制台只剩下了错误提示。并且当执行了追加操作时，out文件的内容非但没有被清空，反而又多了一条a.txt。
同理，我们也可以将错误输出重定向到文件中：
| 1 2 3 4 5 6 7 8 9 |
|
看到这里，朋友们可能会发现>out 2>err和我们在一开头提到的>/dev/null 2>&1已经很像了，别急，这待会再说。
输入重定向
在理解了输出重定向之后，理解输入重定向就会容易得多。对输入重定向的基本命令如下：
| 命令 | 介绍 |
|---|---|
| command <filename | 以filename文件作为标准输入 |
| command 0<filename | 同上 |
| command <<delimiter | 从标准输入中读入，直到遇到delimiter分隔符 |
1.我们使用<对输入做重定向，如果符号左边没有写值，那么默认就是0。
我们这次以cat命令为例，如果cat后面没有跟文件名的话，那它的作用就是将标准输入（比如键盘）回显到标准输出（比如屏幕）上：
| 1 2 3 4 5 |
|
我们可以将利用输入重定向，将我们在键盘上敲入的字符写入到文件中。我们需要使用ctrl+c来结束输入：
| 1 2 3 4 5 6 7 |
|
好了，此时我们觉得自己在键盘上敲比较累，还是直接让cat读取一个文件吧。那么我们需要利用输入重定向：
| 1 2 3 4 5 6 7 |
|
神奇的事情发生了，out文件里面的内容被替换成了input文件里的内容。那么<<又是什么作用呢？我们再看：
| 1 2 3 4 5 6 7 |
|
我们看到，当我们输入完cat >out <<end，然后敲下回车之后，命令并没有结束，此时cat命令像一开始一样，等待你给它输入数据。然后当我们敲入end之后，cat命令就结束了。end之前输入的字符都已经被写入到了out文件中。这就是输入分割符的作用。
高级用法
重定向绑定
好了，在有了以上知识的基础上，我们再来看开头提到的>/dev/null 2>&1。这条命令其实分为两命令，一个是>/dev/null，另一个是2>&1。
1. >/dev/null
这条命令的作用是将标准输出1重定向到/dev/null中。 /dev/null代表linux的空设备文件，所有往这个文件里面写入的内容都会丢失，俗称“黑洞”。那么执行了>/dev/null之后，标准输出就会不再存在，没有任何地方能够找到输出的内容。
2. 2>&1
这条命令用到了重定向绑定，采用&可以将两个输出绑定在一起。这条命令的作用是错误输出将和标准输出同用一个文件描述符，说人话就是错误输出将会和标准输出输出到同一个地方。
linux在执行shell命令之前，就会确定好所有的输入输出位置，并且从左到右依次执行重定向的命令，所以>/dev/null 2>&1的作用就是让标准输出重定向到/dev/null中（丢弃标准输出），然后错误输出由于重用了标准输出的描述符，所以错误输出也被定向到了/dev/null中，错误输出同样也被丢弃了。执行了这条命令之后，该条shell命令将不会输出任何信息到控制台，也不会有任何信息输出到文件中。
>/dev/null 2>&1 VS 2>&1 >/dev/null
再回到文章的开头，我说我弄反了>/dev/null和2>&1拼装的顺序，导致出了一点小问题。乍眼看这两条命令貌似是等同的，但其实大为不同。刚才提到了，linux在执行shell命令之前，就会确定好所有的输入输出位置，并且从左到右依次执行重定向的命令。那么我们同样从左到右地来分析2>&1 >/dev/null：
2>&1，将错误输出绑定到标准输出上。由于此时的标准输出是默认值，也就是输出到屏幕，所以错误输出会输出到屏幕。>/dev/null，将标准输出1重定向到/dev/null中。
我们用一个表格来更好地说明这两条命令的区别：
| 命令 | 标准输出 | 错误输出 |
|---|---|---|
| >/dev/null 2>&1 | 丢弃 | 丢弃 |
| 2>&1 >/dev/null | 丢弃 | 屏幕 |
>/dev/null 2>&1 VS >/dev/null 2>/dev/null
那么可能会有些同学会疑问，为什么要用重定向绑定，而不是像>/dev/null 2>/dev/null这样子重复一遍呢。
为了回答这个问题，我们回到刚才介绍输出重定向的场景。我们尝试将标准输出和错误输出都定向到out文件中：
| 1 2 3 4 |
|
WTF？竟然出现了乱码，这是为啥呢？这是因为采用这种写法，标准输出和错误输出会抢占往out文件的管道，所以可能会导致输出内容的时候出现缺失、覆盖等情况。现在是出现了乱码，有时候也有可能出现只有error信息或者只有正常信息的情况。不管怎么说，采用这种写法，最后的情况是无法预估的。
而且，由于out文件被打开了两次，两个文件描述符会抢占性的往文件中输出内容，所以整体IO效率不如>/dev/null 2>&1来得高。
nohup结合
我们经常使用nohup command &命令形式来启动一些后台程序，比如一些java服务：
| 1 |
|
为了不让一些执行信息输出到前台（控制台），我们还会加上刚才提到的>/dev/null 2>&1命令来丢弃所有的输出：
| 1 |
|
总结
本文主要介绍了linux重定向的原理以及一些基本命令，并且详细地分析了>/dev/null 2>&1这个命令以及一些注意点。
总而言之，在工作中用到最多的就是nohup command >/dev/null 2>&1 &命令，希望大家能够好好掌握。
3043
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
