是否可以在非交互模式下运行 WSL Bash? [英] Is it possible to run WSL Bash in non-interactive mode?

问题描述

人们可能想在 Windows 上的任务计划程序中使用 Bash，或者可能将其用作版本控制挂钩脚本.是否可能或支持?

One may want to use Bash on Windows in Task Scheduler or maybe as version-control hook scripts. Is it possible or supported?

如果不是，为什么?这是一个错误还是防止某些问题的措施?

If not, why? Is it a bug or a measure to prevent some issues?

推荐答案

使用@3d1t0r的解决方案，也可以pipe到cat

Use @3d1t0r's solution, but also pipe to 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往往是多余的

If interactive mode is fine, bash -c is often superfluous

wsl man bash                  # same behavior as `wsl bash -c "man bash"`

上下文(到底什么是交互式"与非交互式"调用?):

上面的例子可能并不完全清楚，但是 man 正在根据它所连接的对象改变它的行为.

Context (what in the world is "interactive" vs "non-interactive" invocation?):

The example above might not make it entirely clear, but man is changing its behavior based on what it's connected to.

• 在交互模式"下，man 让我可以滚动浏览页面，以便以舒适的阅读速度阅读页面.
• 在非交互模式下，man 将整个联机帮助页转储到控制台，让我没有时间阅读任何内容.

• In "interactive mode", man lets me scroll around, so that I can read the page at a comfortable reading pace.
• In noninteractive mode, man dumps the entire manpage to the console, giving me no time to read anything.

但是等等，"我听到你问，难道 man catting 手册页不是因为你要求的吗?我在那儿看到了--man bash |猫"

"But wait," I hear you ask, "isn't man catting the man page because you asked it to? I see it right there--man bash | cat"

不，man 不知道 cat 是什么.它只是获得有关 STDOUT 是否连接到交互式终端的提示.

No, man has no idea what cat is. It just gets hints about whether STDOUT is connected to an interactive terminal.

这是一个不同的例子，它始终 cats:

Here's a different example, that consistently 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 标志.

Now both examples are streaming their output, but the second one is defiantly ignoring my --color flag.

这里的共同点是 man 和 grep 两者的行为是否恰当取决于他们是否认为他们的输出会被某个地方的人通过管道读取.

The common thread here is man and grep both behave appropriately depending on whether they think their output is going to be read by a human piped away somewhere.

自动检测交互性的其他常用命令包括 ls 和 git.通常行为改变将涉及输出分页或颜色(存在其他变体).

Other common commands that auto-detect interactivity include ls and git. Usually the behavior change will involve output paging or colors (other variations exist).

• 分页对人类来说很好，因为人类通常无法以流输出的速度阅读.
• 分页对机器人不利，因为当您只能使用缓冲流时，分页会产生大量协议开销.我的意思是说真的，为什么人类如此缓慢和健谈?
• 颜色对人类来说很好，因为我们喜欢额外的视觉提示来帮助视觉区分.
• 颜色不适合流式传输到文件，因为您的文件将充满 ansi 颜色代码垃圾，大多数文本编辑器都无法很好地显示.

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

Automatic behavior switching based on whether STDOUT is connected to an interactive terminal makes all these use cases usually "just work".

在我的用例和@bahrep 的用例中，交互模式对于无监督脚本(例如，由任务计划程序启动)尤其不利.我猜@bahrep 的预定运行挂在 less 被调用并等待人工输入.

In my use case and @bahrep's use case, interactive mode can be especially bad for unsupervised scripts (e.g. as launched by Task Scheduler). I am guessing @bahrep's scheduled runs hung on less getting invoked and waiting for human input.

出于某种原因，从任务调度程序启动的 wsl 驱动的脚本会给底层脚本错误的提示——它们提示最终输出附加到交互式终端.

For some reason, wsl-driven scripts launched from the task-scheduler give underlying scripts the wrong hints--they hint that the final output is attached to an interactive terminal.

理想情况下，wsl 会从执行环境的 windows 端知道它是否被交互调用，并传递正确的提示.然后我可以运行 wsl [command].在此之前，我需要使用 wsl bash -c "[command] |cat" 作为一种解决方法.

Ideally, wsl would know from the windows side of the execution environment whether it is getting invoked interactively or not, and pass along the proper hint. Then I could just run wsl [command]. Until that happens, I'll need to use wsl bash -c "[command] | cat" as a workaround.

这篇关于是否可以在非交互模式下运行 WSL Bash?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！