加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > Linux > 正文

linux – Bash:多重定向

发布时间:2020-12-14 01:05:36 所属栏目:Linux 来源:网络整理
导读:在脚本的早期,我看到了: exec 32 然后: { $app $conf_file $app_log_file } 13 21 我对此的理解看起来像这样: 创建fd 3 将fd 3输出重定向到stderr (应用程序执行时)将stdout重定向到fd 3,然后将stderr重定向到stdout 这不是某种循环的疯狂吗? 3 GT; stde
在脚本的早期,我看到了:

exec 3>&2

然后:

{ $app $conf_file &>$app_log_file & } 1>&3 2>&1

我对此的理解看起来像这样:

>创建fd 3
>将fd 3输出重定向到stderr
>(应用程序执行时)将stdout重定向到fd 3,然后将stderr重定向到stdout

这不是某种循环的疯狂吗? 3 GT; stderr的>标准输出→3>等?

我特别关注这一行的意图/含义,因为我想开始使用valgrind使用这个脚本运行一些应用程序.我想看看valgrind的输出穿插了应用程序的日志语句,所以我希望stderr的默认输出被上面的混乱线捕获.然而,在导致我想要使用valgrind的一些崩溃中,我已经看到glibc错误直接输出到终端,而不是在应用程序的日志文件中捕获.

那么,问题是:那条执行线到底是做什么的?它捕获了stderr吗?如果是这样,为什么当应用程序崩溃时我在命令行上看到glibc输出?如果没有,我应该如何改变它来实现这一目标?

解决方法

您误读了3>& 2语法.这意味着打开fd 3并使其成为fd 2的副本.见 Duplicating File Descriptors.

以相同的方式,2>& 1并不意味着使fd 2指向fd 1的位置,这意味着重新打开fd 2作为fd 1的副本(大多数是相同的净效果但是不同的语义).

还要记住,所有重定向都会在它们发生时发生,并且这里没有“指针”.因此2>& 1 1> / dev / null不会将标准错误重定向到/ dev / null,它会将标准错误附加到附加到标准输出的地方(可能是终端).

所以有问题的代码是这样做的:

>打开fd 3作为fd 2的副本
>重新打开fd 1作为fd 3的副本
>重新打开fd 2作为fd 1的副本

实际上,这些行将所有内容发送到标准错误(或者在初始执行行运行时附加了fd 2的地方).如果重定向是2>& 1>& 3那么它们将具有交换位置.我想知道这是否是该行的初衷,因为正如所写,这是毫无意义的.

更不用说使用大括号列表中的重定向,大括号列表外部的重定向是相当无用的.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读