使用@3d1t0r 的解决方案，也可以通过管道传递给cat
wsl bash -c "man bash | cat" # noninteractive; streams the entire manpage to the terminal
wsl bash -c "man bash" # shows me the first page, and lets me scroll around; need to hit `q` to exit
如果交互模式很好，bash -c 通常是多余的
wsl man bash # same behavior as `wsl bash -c "man bash"`
上下文（到底什么是“交互式”与“非交互式”调用？）：
上面的例子可能并不完全清楚，但man 正在根据它所连接的对象改变其行为。
- 在“交互模式”下，
man 让我滚动浏览，以便我以舒适的阅读速度阅读页面。
- 在非交互模式下，
man 将整个联机帮助页转储到控制台，让我没有时间阅读任何内容。
“但是等等，”我听到你问，“man catting 手册页不是你要求的吗？我在那儿看到了——man bash | cat”
不，man 不知道cat 是什么。它只是获得有关 STDOUT 是否连接到交互式终端的提示。
这是一个不同的例子，始终如一地cats：
wsl bash -c "echo hey | grep --color e" # colors 'e' red
wsl bash -c "echo hey | grep --color e | cat" # colors disappear, what gives?
现在两个示例都在流式传输它们的输出，但第二个示例完全忽略了我的 --color 标志。
这里的共同点是 man 和 grep 两者的行为是否恰当取决于他们是否认为他们的输出会被某个地方的人通过管道读取。
自动检测交互性的其他常用命令包括ls 和git。通常行为改变将涉及输出分页或颜色（存在其他变体）。
- 分页对人类来说很好，因为人类通常无法以流输出的速度阅读。
- 分页对机器人不利，因为当您只能使用缓冲流时，分页会产生大量协议开销。
I mean seriously, why are humans so slow and chatty?
- 颜色对人类来说很好，因为我们喜欢额外的视觉提示来帮助视觉区分。
- 颜色不适合流式传输到文件，因为您的文件将充满 ansi 颜色代码垃圾，大多数文本编辑器都无法很好地显示。
基于 STDOUT 是否连接到交互式终端的自动行为切换使所有这些用例通常“正常工作”。
重述原始问题
在我的用例和@bahrep 的用例中，交互模式对于无监督脚本（例如，由任务计划程序启动）尤其不利。我猜@bahrep 的预定运行挂在less 被调用并等待人工输入。
出于某种原因，从任务调度程序启动的wsl 驱动的脚本会给底层脚本错误的提示——它们提示最终输出附加到交互式终端。
理想情况下，wsl 会从执行环境的 windows 端知道它是否被交互调用，并传递正确的提示。然后我可以运行wsl [command]。在此之前，我需要使用 wsl bash -c "[command] | cat" 作为解决方法。