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

您可能希望在任务调度程序中使用Windows上的Bash，或者将其用作版本控制挂钩脚本。这是可能的还是得到支持的

---

若否，原因为何？这是一个bug还是一种防止某些问题的措施？

如果我正确理解了您的问题，那么

-c

选项就是您要寻找的。它允许您直接调用Linux命令。
例如，要打开bash的手册页（可能是为了了解

-c

选项）：

注意：如果您转义任何空格（例如

bash-cman\bash

），则可以省去引号，但只使用引号通常更容易，因为第一个未转义的空格将丢失其余的命令。

---

e、 g.

bash-c-man bash

将被解释为与

bash-c-man

使用@3d1t0r的解决方案相同，但也将管道连接到

cat

wslbash-c“manbash | cat”#非交互式；将整个手册页流式传输到终端

wsl bash-c“man bash”#向我显示第一页，并让我四处滚动；需要点击'q'退出

如果交互模式良好，

bash-c

通常是多余的

wsl-man-bash#与'wsl-bash-c“man-bash”的行为相同`

上下文（究竟什么是“交互式”调用与“非交互式”调用？） 上面的例子可能不完全清楚，但是

man

正在根据它所连接的内容改变它的行为

• 在“交互模式”中，

  man

  允许我滚动浏览，这样我就可以以舒适的阅读速度阅读页面
• 在非交互模式下，

  man

  将整个手册页转储到控制台，使我没有时间阅读任何内容

“但是等等，”我听到你问，“男人

cat

不是因为你的要求才去看手册页的吗？我就在那里看到了--

man bash | cat

”

不，

man

不知道什么是

cat

。它只是得到关于STDOUT是否连接到交互终端的提示

下面是一个不同的示例，它始终

cat

s：

wsl bash-c“echo-hey | grep--color e”#将“e”涂成红色

wsl bash-c“echo hey | grep--color e | cat”#颜色消失了，给了什么？

现在，两个示例都在流式传输其输出，但第二个示例公然忽略了我的

--color

标志

这里的共同线索是

man

和

grep

这两种行为是否恰当，取决于它们是否认为自己的输出将被传送到某处的人读取

自动检测交互的其他常见命令包括

ls

和

git

。通常，行为更改将涉及输出分页或颜色（存在其他变化）

• 分页对人类来说很好，因为人类通常无法以流式输出的速度进行读取
• 分页对机器人来说是不好的，因为当您只需要使用缓冲流时，分页会产生大量的协议开销<代码>我是说，说真的，为什么人类那么慢，那么健谈？
• 颜色对人类来说很好，因为我们喜欢额外的视觉线索来帮助视觉区分
• 颜色不利于流式传输到文件，因为您的文件将充满ansi颜色代码垃圾，大多数文本编辑器无法很好地显示这些垃圾

基于STDOUT是否连接到交互终端的自动行为切换使得所有这些用例通常“正常工作”

重申原来的问题 在我的用例和@bahrep的用例中，交互模式对于无监督脚本（例如，由任务调度器启动的脚本）来说可能特别糟糕。我猜@bahrep的计划运行挂起

less

被调用并等待人工输入

出于某种原因，

wsl

驱动的脚本从任务调度器启动，给底层脚本错误的提示——它们提示最终输出附加到交互终端

---

理想情况下，

wsl

将从执行环境的windows端知道它是否被交互调用，并传递适当的提示。然后我就可以运行

wsl[command]

。在这之前，我需要使用

wslbash-c“[command]| cat”

作为解决办法。

不要因为不知道答案就投票关闭。如果你认为我是在寻求软件推荐，请重新阅读问题。PS我知道答案的第一部分，但我想给其他人一个机会来研究这个问题。尽管如此，这个问题的答案也不能被认为是“过于宽泛”。谢谢，你在吗？我的回答回答了你的问题吗？@3D1T0R我在这里。答案是不正确的。怎么了

bash-c“在此处插入Linux命令”

对我很有用。您能否更具体地说明您正试图做什么以及它如何不适合您？@3D1T0R问题是关于WSL（Linux的Windows子系统）。它不支持非交互式会话。

bash -c "man bash"