PowerShell Tee-Object 未捕获文件中的调试行

我有一个通过自动化运行的 PowerShell 脚本，因此我需要将脚本的输出捕获到文件中，但我还想捕获运行的命令，为输出提供一些上下文（我会使用set -x在 Linux shell 脚本中）。不过，我不知道如何将这些命令捕获到 Windows 中的输出文件中；任何帮助深表感谢！

# script.ps1

Set-PSDebug -Trace 1
Write-Host "Hello, World!"

我如何调用脚本（从cmd）：

$ powershell -command "./script.ps1 *>&1 | Tee-Object -FilePath ./output.txt"

终端输出：

DEBUG:    2+  >>>> Write-Host "Hello, World!"
Hello, World!

输出.txt 文件内容：

Hello, World!

您可以看到输出文件缺少终端中显示的调试行。理想情况下，我希望调试行仅位于输出文件中（而不是终端输出），但是在两个地方都有调试线也很好。

请注意，PowerShell 5.1 是我安装的版本。

Unfortunately, PowerShell's tracing output (activated via Set-PSDebug) operates outside PowerShell's system of output streams, so such output cannot be captured from inside a PowerShell session.^[1]

However, an outside caller of PowerShell's CLI^[2], such as cmd.exe in your case, does receive tracing output via stdout (the standard output stream)^[3], so you can use cmd.exe's redirection to capture everything in a file and print it to the console afterwards.

一个简化的例子（来自cmd.exe):

C:\>powershell -c "Set-PSDebug -Trace 1; Write-Host 'Hello, World!'" > output.txt & type output.txt

DEBUG:    1+ Set-PSDebug -Trace 1;  >>>> Write-Host 'Hello, World!'
Hello, World!

^{[1] Perhaps surprisingly, despite the word "Debug" in the cmdlet name, tracing output does not go through stream number 5, the debugging stream, the way that Write-Debug output does.}

^{[2] Note that you can use this technique of calling the CLI, invariably as a child process, from inside an existing PowerShell session as well, in which case that existing session acts as the outside caller. However, note that passing the command to execute via a script block ({ ... }), which is normally preferable, would not work in this case, because a script block-based invocation uses PowerShell's remoting infrastructure behind the scenes, which preserves the PowerShell-specific output streams (and also type fidelity, with limitations), so that the tracing output again goes straight to the console.}

^{[3] Perhaps surprisingly, all of PowerShell's output streams - as well as to-console-only output such as produced by tracing - are by default mapped to an outside caller's stdout stream - including errors. While you can at least separate out errors on demand via a stderr redirection - 2> - on the caller side, all remaining streams are invariably sent to stdout - see the bottom section of this answer and GitHub issue #7989 for more information.}