Bash中的&符号和文件描述符如何理解
这篇文章将为大家详细讲解有关Bash中的&符号和文件描述符如何理解,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。
创新互联公司成立与2013年,是专业互联网技术服务公司,拥有项目成都网站建设、网站建设网站策划,项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命,1280元石嘴山做网站,已为上家服务,为石嘴山各地企业和个人服务,联系电话:13518219792
在我们探究大多数链式 Bash 命令中出现的所有的杂项符号(&
、|
、;
、>
、<
、{
、[
、(
、)
、]
、}
等等)的任务中,我们一直在仔细研究 & 符号。
上次,我们看到了如何使用 & 把可能需要很长时间运行的进程放到后台运行。但是,&
与尖括号 <
结合使用,也可用于将输出或输出通过管道导向其他地方。
在 前面的 尖括号教程中,你看到了如何使用 >
,如下:
ls > list.txt
将 ls
输出传递给 list.txt
文件。
现在我们看到的是简写:
ls 1> list.txt
在这种情况下,1
是一个文件描述符,指向标准输出(stdout
)。
以类似的方式,2
指向标准错误输出(stderr
):
ls 2> error.log
所有错误消息都通过管道传递给 error.log
文件。
回顾一下:1>
是标准输出(stdout
),2>
是标准错误输出(stderr
)。
第三个标准文件描述符,0<
是标准输入(stdin
)。你可以看到它是一个输入,因为箭头(<
)指向0
,而对于 1
和 2
,箭头(>
)是指向外部的。
标准文件描述符有什么用?
如果你在阅读本系列以后,你已经多次使用标准输出(1>
)的简写形式:>
。
例如,当(假如)你知道你的命令会抛出一个错误时,像 stderr
(2
)这样的东西也很方便,但是 Bash 告诉你的东西是没有用的,你不需要看到它。如果要在 home/
目录中创建目录,例如:
mkdir newdir
如果 newdir/
已经存在,mkdir
将显示错误。但你为什么要关心这些呢?(好吧,在某些情况下你可能会关心,但并非总是如此。)在一天结束时,newdir
会以某种方式让你填入一些东西。你可以通过将错误消息推入虚空(即 `/dev/null
)来抑制错误消息:
mkdir newdir 2> /dev/null
这不仅仅是 “让我们不要看到丑陋和无关的错误消息,因为它们很烦人”,因为在某些情况下,错误消息可能会在其他地方引起一连串错误。比如说,你想找到 /etc
下所有的 .service
文件。你可以这样做:
find /etc -iname "*.service"
但事实证明,在大多数系统中,find
显示的错误会有许多行,因为普通用户对 /etc
下的某些文件夹没有读取访问权限。它使读取正确的输出变得很麻烦,如果 find
是更大的脚本的一部分,它可能会导致行中的下一个命令排队。
相反,你可以这样做:
find /etc -iname "*.service" 2> /dev/null
而且你只得到你想要的结果。
文件描述符入门
单独的文件描述符 stdout
和 stderr
还有一些注意事项。如果要将输出存储在文件中,请执行以下操作:
find /etc -iname "*.service" 1> services.txt
工作正常,因为 1>
意味着 “发送标准输出且自身标准输出(非标准错误)到某个地方”。
但这里存在一个问题:如果你想把命令抛出的错误信息记录到文件,而结果中没有错误信息你该怎么做?上面的命令并不会这样做,因为它只写入 find
正确的结果,而:
find /etc -iname "*.service" 2> services.txt
只会写入命令抛出的错误信息。
我们如何得到两者?请尝试以下命令:
find /etc -iname "*.service" &> services.txt
…… 再次和 &
打个招呼!
我们一直在说 stdin
(0
)、stdout
(1
)和 stderr
(2
)是“文件描述符”。文件描述符是一种特殊构造,是指向文件的通道,用于读取或写入,或两者兼而有之。这来自于将所有内容都视为文件的旧 UNIX 理念。想写一个设备?将其视为文件。想写入套接字并通过网络发送数据?将其视为文件。想要读取和写入文件?嗯,显然,将其视为文件。
因此,在管理命令的输出和错误的位置时,将目标视为文件。因此,当你打开它们来读取和写入它们时,它们都会获得文件描述符。
这是一个有趣的效果。例如,你可以将内容从一个文件描述符传递到另一个文件描述符:
find /etc -iname "*.service" 1> services.txt 2>&1
这会将 stderr
导向到 stdout
,而 stdout
通过管道被导向到一个文件中 services.txt
中。
它再次出现:&
发信号通知 Bash 1
是目标文件描述符。
标准文件描述符的另一个问题是,当你从一个管道传输到另一个时,你执行此操作的顺序有点违反直觉。例如,按照上面的命令。它看起来像是错误的方式。你也行像这样阅读它:“将输出导向到文件,然后将错误导向到标准输出。” 看起来错误输出会在后面,并且在输出到标准输出(1
)已经完成时才发送。
但这不是文件描述符的工作方式。文件描述符不是文件的占位符,而是文件的输入和(或)输出通道。在这种情况下,当你做 1> services.txt
时,你的意思是 “打开一个写管道到 services.txt
并保持打开状态”。1
是你要使用的管道的名称,它将保持打开状态直到该行的结尾。
如果你仍然认为这是错误的方法,试试这个:
find /etc -iname "*.service" 2>&1 1>services.txt
并注意它是如何不工作的;注意错误是如何被导向到终端的,而只有非错误的输出(即 stdout
)被推送到 services.txt
。
这是因为 Bash 从左到右处理 find
的每个结果。这样想:当 Bash 到达 2>&1
时,stdout
(1
)仍然是指向终端的通道。如果 find
给 Bash 的结果包含一个错误,它将被弹出到 2
,转移到 1
,然后留在终端!
然后在命令结束时,Bash 看到你要打开 stdout
(1
) 作为到 services.txt
文件的通道。如果没有发生错误,结果将通过通道 1
进入文件。
相比之下,在:
find /etc -iname "*.service" 1>services.txt 2>&1
1
从一开始就指向 services.txt
,因此任何弹出到 2
的内容都会导向到 1
,而 1
已经指向最终去的位置 services.txt
,这就是它工作的原因。
在任何情况下,如上所述 &>
都是“标准输出和标准错误”的缩写,即 2>&1
。
这可能有点多,但不用担心。重新导向文件描述符在 Bash 命令行和脚本中是司空见惯的事。
关于Bash中的&符号和文件描述符如何理解就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
分享标题:Bash中的&符号和文件描述符如何理解
分享链接:http://myzitong.com/article/gghdhs.html