是否可以在非交互模式下运行WSL Bash？

Question

有人可能想在任务计划程序中使用Windows上的Bash，或者可能想要使用版本控制挂钩脚本。是可能的还是支持的？

如果没有，为什么？这是一个防止某些问题的错误或措施吗？

Answer 1

使用@ 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将整个联机帮助页转储到控制台，使我没有时间阅读任何内容。

“等等，”我听到你问，“不是因为你要求而{@ {1}}来设置手册页吗？我在那儿看到了-cat”

否，man bash | cat不知道man是什么。它只是暗示STDOUT是否已连接到交互式终端。

这是另一个示例，始终cat s：

cat

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
• 颜色对人类很好，因为我们喜欢其他视觉线索以帮助视觉区分。
• 颜色不利于流式传输到文件，因为您的文件将充满ansi颜色代码垃圾，大多数文本编辑器的显示效果都不佳。

基于STDOUT是否已连接到交互式终端的自动行为切换，使得所有这些用例通常都“可行”。

重新确定原始问题

在我的用例和@bahrep的用例中，交互模式对于不受监督的脚本（例如，由Task Scheduler启动的脚本）尤其不利。我猜想@bahrep的预定运行会挂在I mean seriously, why are humans so slow and chatty?上，并等待人工输入。

由于某种原因，从任务计划程序启动的less驱动的脚本为基础脚本提供了错误的提示-它们提示最终输出将附加到交互式终端。

理想情况下，wsl从执行环境的Windows端知道它是否被交互调用，并传递适当的提示。然后，我可以运行wsl。在此之前，我需要使用wsl [command]作为解决方法。

Answer 2

如果我正确理解您的问题，-c选项就是您正在寻找的选项。它允许您直接调用Linux命令 例如，要打开bash的手册页（可能是为了查找-c选项）：

bash -c "man bash"

注意：如果您逃离任何空格（例如bash -c man\ bash），您可以不使用引号，但通常更容易使用引号，因为第一个未转义的空格会丢失其余的空格命令。
例如bash -c man bash的解释与bash -c man相同。