少用管道?


25

可以更少地跟踪(通过按F)管道输入(类似于文件)吗?对于正在写入的文件,命令

less <file>

按F时将跟随文件。

但是如果我有一条命令将输出直接传送到更少的内容,像这样

command | less

按F不会执行任何操作。

如此看来,管道无法像文件一样被追踪?也许与写STDERR的命令有关?我试图实现的效果始终是看到命令的最新输出:就像按住PageDown一样!

有一个相关的说法适用于G(结束):当直接传递给小号时,它将不起作用。


Answers:


21

FG品牌less力争达到输入EOF。如果输入是管道,则less挂起,直到另一侧的管道关闭为止(并且不执行任何操作)。

通过将命令输出保存到后台的临时文件中,然后将其用作以下命令的输入,可以解决此问题less

command > /tmp/x &
less +F /tmp/x; kill %; rm /tmp/x

没有选择只能这样做less。但是,我承认这会很有用。


如果输入是管道,则less挂起,直到另一侧的管道关闭。那是一种误导性陈述。什么情况是,少通话read在阻塞模式,等待新的数据或管道的关闭。
Piotr Dobrogost,2014年

3
在管道输入上按F或G后,less不仅会读取阻塞,而且还会在循环中等待EOF。而且,仅当管道的另一侧关闭时,管道上的EOF才会发生。
mik

3
如果less要在该循环中更新屏幕,就不会有问题。阻止读取与此问题无关。
mik

1
@Flow这不是问题的症结所在,在这种情况下只是一个等待-在达到EOF时等待文件中的更多数据(顺便说一句,对于封闭的管道不会发生),或中断以退出跟随模式
mik

1
less如果没有数据,则阻止读取的@PiotrDobrogost 将无法更新屏幕;当出现某些数据时,阻塞读取将返回它,并且less能够在没有单独线程的情况下更新屏幕
mik

6

可以更少地跟踪(通过按F)管道输入(类似于文件)吗?

是的,从版本474开始。但是,任何版本的发行说明中都未提及该功能,因为此功能目前还有一个问题。以下是更少的维护者Mark Nudelman的评论:

关于管道上的F命令,此问题也已在less-474中修复。F命令而不是寻求EOF,而是寻找到缓冲输入的末尾并从那里开始读取。但是,它并不是真正可用的,因为当您按下CTRL-C来停止F命令时,它将杀死产生输出的进程。我不确定该如何解决。

在此问题得到解决之前,很少有人可以使用Shell功能解决该问题。请参阅我的回答是否有任何方法可以在不停止管道中其他进程的情况下退出“较少”关注模式?询问细节。

作为参考,F无法与管道配合使用的问题在已知错误列表上的参考号为300,其标题为F命令不适用于管道输入。


有一个相关的说法适用于G(结束):当直接传递给小号时,它将不起作用。

它从466版本开始起作用。从该版本的发行说明中引用:

新命令ESC-G转到管道中当前缓冲数据的末尾


ESC-G命令是在2014
。– mik 2015年

@mik看起来像是版本471的发行说明中的​​错误。谢谢,固定。
Piotr Dobrogost,2015年

这不是错误,它们只是从稳定版本(在这种情况下为458版)开始,逐步列出更改。但是,ESC-G命令没有稳定的版本。
mik

ESC-G命令现在处于稳定版本中(481):“ 2015年10月16日,less-481已发布,可用于一般用途”。
mik

更新:关于管道上的F命令,此问题已在less-474中修复。F命令而不是寻求EOF,而是寻找到缓冲输入的末尾并从那里开始读取。但是,它并不是真正可用的,因为当您按下ctrl-C来停止F命令时,它将杀死产生输出的进程。我不确定该如何解决。–少维护者Mark Nudelman
Piotr Dobrogost

2

从更少的手册页

[Keyboard] COMMANDS [...]

   F      Scroll  forward, and keep trying to read when the end of file is reached.  Normally this command would be used when already
          at the end of the file.  It is a way to monitor the tail of a file which is growing while it is being viewed.  (The  behav‐
          ior is similar to the "tail -f" command.)

所以这应该有效,并且实际上对我有效。


1
当与@mik描述的管道一起使用时,此命令的行为有所不同,并且显然不是OP所寻找的。
Piotr Dobrogost,2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.