less 在 env 内调用时不会对输出进行分页

Question

更新后，我注意到我的着色 bash 配置文件man中断了分页。我不知道发生了什么变化，但我将范围缩小到这样一个事实：调用env less hello.txt会导致内容hello.txt回显到终端（如cat），而没有分页行为。我该如何调试和修复这个问题？

为了消除一些环境变量的影响，我用最小环境进行了测试：

env -i TERM=xterm-256color /usr/bin/less hello.txt

甚至：

env -i /usr/bin/less hello.txt

这也只是将文件打印到标准输出。在具有相同软件版本的不同计算机上，分页可以工作（如果TERM保留）。

由于 Even 的env -i行为不同，我不认为原因是我的环境中的某些原因。

less和的版本env相同：less 581.2 (PCRE2 regular expressions)和GNU coreutils 8.32，操作系统是 Arch Linux 64 位，最新，shell：GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)。

Answer 1

env foo …与普通的行为不同的最可能的解释foo …是它foo是一个函数或别名。由于env是外部命令，因此它会查找foo为外部命令。

但在这里，env它本身就是一个别名。显然，如果env不是标准env命令，它的行为可能会有所不同。

事实证明这是一个错误GRC它设置了一个文件包含在 bash 启动期间（还有 zsh 和 Fish 版本）它定义了许多命令，包括env, 作为别名：env别名为grc -es env.grc -es …运行指定的命令，其标准输出和标准错误都重定向到管道，在管道中grc插入转义序列以更改文本颜色。这对于产生人们想要以良好格式读取的输出的命令来说是很好的。但对 执行此操作没有意义env，该命令的主要作用是使用修改后的环境调用另一个命令。foo当用户运行时自动将输出和错误输出重定向到管道env foo是具有破坏性的，并且无论如何它都是无用的，因为 grc 不知道如何对输出进行着色。我猜目标是对env不带参数的输出进行着色，这会显示环境，但这几乎没有用，因为env首先的输出不是很用户友好：export做得更好，因为与env它生成排序输出不同（并以一种使带有换行符的值明确的形式引用）。