今天,我注意到我从一个在启动时验证其文件描述符的工具中得到了一个错误。事实上,我得到了一个额外的pts连接:
# In one console I start `cat`
linux $ cat >/tmp/test
# In another console I search for `cat`'s process ID
linux $ ps -ef | grep cat
alexis 34462 25012 0 11:58 pts/17 00:00:00 cat
# Now check the file descriptors:
linux $ ls -l /proc/34462/fd
total 0
lrwx------ 1 alexis alexis 64 Sep 23 11:59 0 -> /dev/pts/17
l-wx------ 1 alexis alexis 64 Sep 23 11:59 1 -> /tmp/test
lrwx------ 1 alexis alexis 64 Sep 23 11:59 2 -> /dev/pts/17
lrwx------ 1 alexis alexis 64 Sep 23 11:59 6 -> /dev/pts/17正如我们所看到的,stdin被设置为目标文件名/tmp/test。如预期的那样,0和2被设置为pts。
不过,6是什么?
我在想,也许它来自于我的rails环境。rvm脚本对我的控制台产生了一些“魔力”,当我将cd放入一个名为Gemfile的目录中时,它会检测到它。话虽如此,我以为那只是一个cd的别名.还有什么可以在我的命令行中添加这样的文件描述符吗?我能做些什么来测试它的来源以及它提供的功能?
更新:我可以确认,如果我在注释掉RVM初始化(. ~/.rvm/scripts/rvm .)之后打开一个新控制台,那么我就不会得到额外的伪终端文件描述符。我还在想他们怎么能做到呢?
发布于 2020-09-23 20:47:37
RVM将打开一个新的文件描述符,用于当前在启动时连接到的任何标准错误。因此,在RVM环境中,文件描述符6是RVM日志输出。这样,无论标准错误是否被重定向,RVM都可以通过将输出写入文件描述符6来登录到相同的位置。
打开文件描述符在…的最后scripts/functions/logging。
exec 6>&2
没有参数但有重定向的exec内置在shell进程中执行重定向。因此,exec 6>&2将文件描述符6打开到shell中的任何文件描述符2。从shell启动的程序继承此文件描述符。
当RVM想要记录某些内容时,它(通常)会输出到文件描述符6。例如,在这个rvm_error函数中就会发生这种情况。
例如,在从终端启动的RVM环境中执行以下代码,它将“发生的事情”写入myfile.log,但将Hello写入终端。
f () {
…
echo >&2 "Stuff happened"
rvm_error "Hello"
}
f 2>myfile.log发布于 2020-09-23 20:17:37
该特殊文件包含当前线程futex上下文句柄。
https://unix.stackexchange.com/questions/611012
复制相似问题