为什么 unbuffer -p 会破坏其输入?

为什么 unbuffer -p 会破坏其输入?
$ seq 10 | unbuffer -p od -vtc
0000000   1  \n   2  \n   3  \n   4  \n   5  \n   6  \n   7  \n   8  \n

9去了哪里10

$ printf '\r' | unbuffer -p od -An -w1 -vtc
  \n

为什么\r改为\n

$ : | unbuffer -p printf '\n' | od -An -w1 -vtc
  \r
  \n
$ unbuffer -p printf '\n' | od -An -w1 -vtc
  \r
      \n

搞什么?

$ printf foo | unbuffer -p cat
$

为什么没有输出(并且延迟一秒)?

$ printf '\1\2\3foo bar\n'  | unbuffer -p od -An -w1 -vtc
$

为什么没有输出?

$ (printf '\23'; seq 10000) | unbuffer -p cat

为什么它挂起并且没有输出?

$ unbuffer -p sleep 10

为什么我看不到我输入的内容(为什么即使sleep我没有阅读它也会被丢弃)?

顺便说一句,还有:

$ echo test | unbuffer -p grep foo && echo found foo
found foo

为什么grep找到foo但没有打印包含它的行?

$ unbuffer -p ls /x 2> /dev/null
ls: cannot access '/x': No such file or directory

为什么错误没有转到/dev/null

也可以看看取消缓冲将所有字符转换为响铃?

$ echo ${(l[10000][foo])} | unbuffer -p cat | wc -c
4095

那是:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux trixie/sid
Release:        n/a
Codename:       trixie
$ uname -rsm
Linux 6.5.0-3-amd64 x86_64
$ expect -c 'puts "expect [package require Expect] tcl [info patchlevel]"'
expect 5.45.4 tcl 8.6.13
$ /proc/self/exe --version
zsh 5.9 (x86_64-debian-linux-gnu)

在 Ubuntu 22.04 或 FreeBSD 12.4-RELEASE-p5 上也是如此(除了od命令必须在那里进行调整,我得到 2321(那里的所有 BEL 字符)而不是上面的 4095)。

答案1

unbuffer是一个工具,用于禁用某些命令在其输出未发送到终端设备时执行的缓冲。

当它们的输出发送到终端设备时,命令假设有一个实际用户正在主动查看输出,因此它们会在输出可用时立即发送它。嗯,不完全是,他们基于行发送,即一旦准备好输出就发送完整的行。

当它不发送到终端设备时,例如当 stdout 是常规文件或管道时,作为优化,它们会以块的形式发送它。这意味着更少的write()s,并且在管道的情况下意味着另一端的读取器不需要经常被唤醒,这意味着更少的上下文切换。

然而,这意味着:

cmd | other-cmd

在终端中运行,其中other-cmd有某种过滤/转换命令,other-cmd的 stdout 是行缓冲的,但cmds 是全缓冲的,这意味着交互式用户不会尽快看到 的输出cmd(由 转换)other-cmd因为它是可用的,但延迟并且是大批量的。

unbuffer cmd | other-cmd

有帮助,因为它恢复了基于行的缓冲,cmd即使它的标准输出将进入管道。

为此,它cmd从伪终端开始,并将来自该伪终端的内容转发到管道。因此cmd认为它再次与用户交谈并进行行缓冲。

unbuffer实际上写在expect.它是中的示例脚本expect源代码,通常包含在expect操作系统提供的软件包中。

expect是一个用于使用伪终端与终端应用程序执行自动交互的工具,因此该unbuffer命令写入起来很简单expect.开玩笑地说,错误的部分unbuffer的手册页手册页比程序长。确实,程序只是:

#!/bin/sh
# -*- tcl -*-
# The next line is executed by /bin/sh, but not tcl \
exec tclsh8.6 "$0" ${1+"$@"}

package require Expect


# -*- tcl -*-
# Description: unbuffer stdout of a program
# Author: Don Libes, NIST

if {[string compare [lindex $argv 0] "-p"] == 0} {
    # pipeline
    set stty_init "-echo"
    eval [list spawn -noecho] [lrange $argv 1 end]
    close_on_eof -i $user_spawn_id 0
    interact {
        eof {
            # flush remaining output from child
            expect -timeout 1 -re .+
            return
        }
    }
} else {
    set stty_init "-opost"
    set timeout -1
    eval [list spawn -noecho] $argv
    expect
    exit [lindex [wait] 3]
}

正如您所看到的以及手册页所确认的,unbuffer还支持一个-p选项。

在 中unbuffer cmd,伪终端不仅连接到 cmd 的 stdout,还连接到它的 stdin 和 stderr(记住expect是一个旨在与命令交互的工具):

$ tty; unbuffer readlink /proc/self/fd/{0..2}
/dev/pts/14
/dev/pts/15
/dev/pts/15
/dev/pts/15

这解释了为什么unbuffer ls /x 2> /dev/null没有将错误发送到/dev/null,stderr 与 stdout 合并。

现在,unbuffer不从其自己的标准输入读取任何内容,也不向 的标准输入发送任何内容cmd

这意味着A | unbuffer cmd | B行不通。

这就是-p(for pipe) 选项的用武之地。如代码中所示, with -p,unbuffer使用interact而不是expect作为处理来自不同通道的数据的活动循环。

仅使用该expect语句,expect(程序/TCL 库)读取来自伪终端的内容(cmd例如通过其 stdout 或 stderr 在从机端写入的内容),然后将其发送到自己的 stdout。

使用interact,expect不仅可以:

  • 将从自己的标准输入读取的内容发送到伪终端(以便cmd可以在那里读取)
  • 另外,如果unbuffer的 stdin 恰好是终端设备,interact则将其置于raw本地echo禁用模式。

这很好,因为A | unbuffer -p cmd | B,A的输出可以被读取为输入,cmd但意味着以下几点:

  • unbuffer使用 来配置内部伪终端set stty_init "-echo",但不在raw模式下。特别是, ( ( ) // isig的处理)、(流量控制,/ ( ))不会被禁用。当输入是终端设备时(这就是s 的使用方式,而不是),这很好,因为主机设备处于模式,这意味着处理从主机终端转移到嵌入式伪终端终端,除了这两个终端都被禁用,所以你看不到你输入的内容。但是,当它不是终端设备时,这意味着输入中的任何 0x3 字节 ( )(当处理 的输出时)都会触发 SIGINT 并终止命令,任何 0x19 字节 ( ) 都会停止流程。未被禁用解释了为什么s 更改为s。^C\3^Z^\ixon^Q^S\23expectinteractunbufferrawecho^Cprintf '\3'printf '\23'icrnl\r\n

  • 它不会做它stty -opost没有的情况下所做的事情-p。这解释了为什么\n的输出cmd被更改为\r\n.当输入是终端设备时,它将该设备放入 中raw,因此opost使用禁用这一事实解释了当 输出的换行符od未转换为 时,终端输出被破坏\r\n

  • 内部伪终端仍然启用行编辑器,因此cmd除非有来自输入的\r或字符,否则不会发送任何内容,这解释了为什么不打印任何内容。\nprintf foo | unbuffer -p cat

    由于该行编辑器对行的大小有限制,因此可以编辑(我的系统 (Linux) 上为 4095,tty 速度的五分之一1 在 FreeBSD 上),你最终会遇到这样的问题:取消缓冲将所有字符转换为响铃?:当您尝试在哑应用程序(例如 )中在键盘上输入过长的行时,会发生同样的情况cat。在 Linux 上,4094 个之后的所有字符都将被忽略,但\n会被接受并提交该行;在 FreeBSD 上,输入 38400/5 个字符后,任何多余的字符都会被拒绝(甚至\n),并导致 BEL 被发送到终端²。这解释了为什么你在那里得到 2321 BEL (10001 - 38400/5)。

  • 伪终端设备的 EOF 处理很笨重。当 的 stdin上看到 EOF 时unbuffer,它无法将该信息转发到cmd.因此seq 10 | od -vtc,在seq终止后,od仍在等待来自伪终端的更多输入,而这些输入永远不会到来。相反,到那时,一切都被拆除并被od杀死(手册页确实提到了这个限制)。

unbuffer就其自身目的而言,如果将嵌入式伪终端置于raw -echo模式下并保留主机终端设备(如果有),效果会更好。然而expect并不真正支持这种操作模式,它不是为此设计的。

现在,如果unbuffer是关于取消缓冲标准输出,那么它没有理由接触标准输入和标准错误。

我们实际上可以通过以下方式解决这个问题:

unbuffer() {
  command unbuffer sh -c 4<&0 5>&2 '
    exec <&4 4<&- 2>&5 5>&- "$@"' sh "$@"
}

它用于sh恢复原始的 stdin 和 stderr(由调用 shell 通过 fds 4 和 5 传递;不使用 fd 3,就像expect在内部显式使用该 fd 3 一样)。

然后:

$ echo test | unbuffer readlink /proc/self/fd/{0..2} 2> /dev/null | cat
pipe:[184479]
/dev/pts/16
/dev/null

只有 stdout 进入伪终端以进行无缓冲。

所有其他问题都消失了:

$ unbuffer ls /x 2> /dev/null
$ printf '\r'  | unbuffer od -An -w1 -vtc
  \r
$ : | unbuffer printf '\n' | od -An -w1 -vtc
  \n
$ unbuffer printf '\n' | od -An -w1 -vtc
  \n
$ printf foo | unbuffer cat
foo
$ printf '\1\2\3foo bar\n' | unbuffer od -An -w1 -vtc
 001
 002
 003
   f
   o
   o

   b
   a
   r
  \n
$ (printf '\23'; seq 10000) | unbuffer cat -vte | head
^S1$
2$
3$
4$
5$
6$
7$
8$
9$
10$
$ unbuffer sleep 10
I see what I type
$ I see what I type
zsh: command not found: I
$ echo test | unbuffer grep foo || echo not found
not found
$ echo ${(l[10000][foo])} | unbuffer cat | wc -c
10001

当您需要的只是通过伪终端进行标准输出时,安装expect(需要 TCL 解释器)似乎有点矫枉过正。cmd

socat也可以这样做:

$ echo test | socat -u system:'readlink /proc/self/fd/[0-2]; wc -c',pty,raw - 2> /dev/null | cat
pipe:[187759]
/dev/pts/17
/dev/null
5

(它记录失败退出状态,但不会传播命令的退出状态)。

shellzsh甚至内置了对伪 ttys 的支持,并且unbuffer可以轻松地编写一个函数:

zmodload zsh/zpty
zmodload zsh/zselect
unbuffer() {
  {
    return "$(
      exec 6>&1 >&5 5>&-
      # here fds go:
      #  0,3: orig stdin
      #    1: orig stdout
      #  2,4: orig stderr
      #    5: closed
      #    6: to return argument
      zpty -b unbuffer '
        stty raw
        exec <&3 3<&- 2>&4 4>&-
        # here fds go:
        #     0: orig stdin
        #     1: pseudo unbuffering tty
        #     2: orig stderr
        # 3,4,5: closed
        #     6: to return argument
        "$@" 6>&-
        echo "$?" >&6 
      '
      fd=$REPLY
      until
        zselect -r $fd
        zpty -r unbuffer
        (( $? == 2 ))
      do
        continue
      done
    )"
  } 3<&0 4>&2 5>&1
}

请注意,所有这些最终都会在新终端中运行,除了新会话中的socat方法(除非您使用ctty和选项)。setid因此,现在如果这些“fixed”unbuffer在主机终端会话的后台启动,则cmd不会停止从主机终端读取数据。例如,unbuffer cat&最终会从您的终端读取后台作业,从而造成严重破坏。


1 上限为 65536。速度对于伪终端来说是无关紧要的,但必须有一个广告,我发现在我测试的 FreeBSD 系统上默认情况下它是 38400。由于速度是从控制终端的速度复制的expect,因此可以在调用之前执行stty speed 115200(最大值AFAICT)unbuffer以扩大该缓冲区。但您可能会发现您仍然没有获得完整的 10000 字符大行。那是驱动代码中解释了。您会发现unbuffer -p cat仅返回 4096 字节,因为这是cat第一次调用时所请求的字节数read(),并且 tty 驱动程序从输入行返回了同样多的字节数但丢弃了其余的(!)。如果替换为unbuffer -p dd bs=65536,您将获得完整的行(最多 115200/5 字节)。

² 您可以通过在脚本中替换set stty_init "-echo"为来避免这些 BEL ,但这不会帮助您获取数据。set stty_init "-echo -imaxbel"unbuffer

相关内容