什么決定是否從PowerShell函式回傳值？

我試圖弄清楚是什么決定了一個值是否從 PowerShell 函式回傳，但我遇到了一些奇怪的問題。該about_return檔案說：

在 PowerShell 中，即使沒有包含 Return 關鍵字的陳述句，每個陳述句的結果也會作為輸出回傳。

但這似乎掩蓋了細節。如果我運行這個：

function My-Function {
    1
    [System.Console]::WriteLine("Hello")
    $null
    $true
    $false
    0
    2
}

運行它會回傳一個陣列（以及列印“Hello”）：

1
True
False
0
2

這意味著它$null不會自動回傳。然后我嘗試遞增，因為我在函式中使用它：

function My-Function {
    $n = 1
    $n
    $n  
    ($n  )
    -join @(1, 2, 3)
    (-join @(1, 2, 3))
}

回傳：

1
2
123
123

所以，$n并且$n 被退回了，但($n )不是嗎？但是當與另一個運算子 ( -join)相比時，它在每種情況下都是相同的。為什么環繞括號會$n 阻止它被回傳，為什么其他運算子的行為不一樣？這更加令人困惑，因為=運算子似乎以相反的方式作業：

function My-Function {
    ($n = 1)
    $n
    $n  
    ($n  )
}

回傳：

1
1
2

現在包裝賦值會導致它被回傳，而包裝$n 導致它不被回傳。

總之，我只想知道一種能夠查看函式中的一行代碼并確定它是否會導致回傳值的直接方法。

uj5u.com熱心網友回復：

本節討論示例函式中的特定陳述句。
有關背景資訊，請參閱底部部分。

• $n = 1并且$n 是賦值，因此不產生輸出。
• $n是一個運算式，其值是輸出
• $null- 同上，但即使是輸出，默認情況下也不顯示
• ($n )- 由于封閉(...)- 將分配轉換為運算式，因此確實輸出分配的值（也）。
  • 但是，因為您使用了賦值的后增量形式，所以輸出的是舊值，而不是現在增加的值；先遞增（預遞增）然后輸出，使用( $n)
• [System.Console]::WriteLine("Hello")直接列印到控制臺，它繞過了PowerShell 的輸出流系統。
  • 這意味著您無法從 PowerShell 內部捕獲或重定向此類輸出（請參閱下一節）。

PowerShell 的輸出（“回傳值”）行為：

^{向iRon 致敬以尋求他的幫助。}

PowerShell遵循傳統 shell 的模型，圍繞流組織-有關 PowerShell 支持的所有 6 個流的概述，請參閱概念about_Redirection幫助主題。^[1]

也就是說，腳本或函式中的任何陳述句（因此可能是多個陳述句）都可以寫入任何輸出流。

所述主輸出流，為了傳達資料，是成功的輸出流（其數量1），并且只有它通過發送管道默認，因此默認只有它在一個變數中被捕獲，抑制，或重定向到一個檔案。

有兩種方法可以寫入成功輸出流，即產生資料輸出：

• 明確地，通過Write-Output呼叫——盡管很少需要這樣做。

• 通常是隱式的，既不捕獲、抑制也不重定向陳述句產生的輸出。

  • 換句話說：默認情況下，任何命令（例如，Get-ChildItem *.txt）或運算式（例如，1 2）的輸出都會發送到成功輸出流。

  • 不同于傳統的編程語言，return是不是需要產生輸出-事實上，它的主要目的是退出封閉范圍獨立地范圍產生任何輸出的，但作為一個語法上的方便，你可以結合這兩個方面的內容：

    • return <command-or-expression>實際上與以下兩個陳述句相同，其中第一個（可能）產生輸出，第二個退出范圍：<command-or-expression>; return

  • 這種隱式輸出行為很方便，并且允許撰寫簡潔、富有表現力的代碼，但也可能是一個陷阱：很容易意外產生輸出- 通常來自不需要回傳值的 .NET 方法（請參閱此問題的示例）。

    • iRon 的GitHub 功能請求 # 15781討論了一種解決此問題的潛在方法：引入僅允許使用顯式輸出陳述句 ( Write-Output, return) 來生成輸出的選擇加入嚴格模式。

    • 此答案顯示了可用于當前可用功能的故障排除技術。

至于任務- 例如$n = 1; $n = 1; $n; $n--：

• 默認情況下，他們也不會產生輸出。
  • 甲混合情況下是一個的鏈接形式的多分配，例如$a = $b = 1，其受讓人1于兩個變數：陳述書內部 的分配值被通過，但宣告作為一個整體沒有輸出。
• However, as an opt-in you can make them pass the value(s) being assigned through via (...), the grouping operator; e.g. ($n = 1) both assigns 1 to variable $n and outputs 1, which allows it to participate in larger expressions, such as ($n = 1) -gt 0
  • Note that the related $(...) (subexpression operator) and @(...) (array-subexpression operator) do not have that effect - they wrap one or more entire statement(s), without affecting the enclosed statements' intrinsic output behavior; e.g. $($n = 1) does not produce output, because $n = 1 by itself doesn't produce output; however, $(($n = 1)) does, because ($n = 1) by itself does.

As for output enumeration behavior:

• By default, PowerShell enumerates collections that are being output, in the spirit of streaming output: That is, it sends a collection's elements to the pipeline, one by one.

• In the rare event that you do need to output a collection as a whole - which in general should be avoided, so as not to confound other commands participating in a pipeline, which usually do expect object-by-object input - you have two options:

  • , $collection (sic; uses an aux. one-element wrapper array)
  • More explicitly, but less efficiently: Write-Output -NoEnumerate $collection
  • See this answer for more information.

As for outputting $null:

• $null is output to the pipeline, but by default doesn't show.

  • $null by itself produces no visible output,

  • but the following returns $true, demonstrating that the value was sent:

    $null | ForEach-Object { $null -eq $_ } # -> $true
    

• Note that PowerShell also has an "array-valued $null" value that it uses to represent the lack of output from a command, which is technically represented as the [System.Management.Automation.Internal.AutomationNull]::Value singleton. In expression contexts, this values is treated the same as $null, but in the pipeline it behaves like an enumerable without elements and therefore sends nothing through the pipeline - see this answer for more information.

As for suppressing (discarding) unwanted output / redirecting to a file:

• The best general-purpose way to suppress a statement's success output is to assign to $null ($null = ...); e.g.:

   # .Add() outputs a value, which is usually unwanted.
   $null = ($list = [System.Collections.ArrayList]::new()).Add('hi')
  

  • See this answer for a discussion and alternatives.

• Note: The following discusses output suppression, via $null as the redirection target, but applies analogously to redirecting output to a file, by specifying a file name or path as the target.^[2]

  • To selectively suppress a different output stream, prefix >$null with its number; e.g. 3>$null suppresses warning stream output.

  • To suppress output from all streams, which in the case of external programs covers both stdout and stderr, use redirection *>$null.

As for merging output streams:

• Only the success output stream (stream number 1) can be merged into.
• You can selectively merge one or more output streams into it (e.g. 2>&1 and/or 3>&1), or merge all (others): *>&1
• In the resulting merged success output stream you can still identify what (non-success) stream a given object came from, by examining its type; e.g., error stream objects (stream 2) are [System.Management.Automation.ErrorRecord] instances - see this answer for more information.

As for bypassing PowerShell's system of streams:

• Out-Host and [Console]::WriteLine() calls bypass PowerShell's output streams and write directly to the host / console (terminal). (A host is any environment that hosts the PowerShell engine, which is typically, but not necessarily a console (terminal); examples of other hosts are the PowerShell SDK and the host used in PowerShell remoting).

  • As such, their output cannot be captured, suppressed or redirected from inside PowerShell.

• Write-Host formerly unconditionally bypassed PowerShell's output streams and still goes to the host by default, but - since PowerShell version 5 - routes its output via the information stream (stream number 6), where it can be captured / redirected on demand - see this answer for more information.

As for how output is formatted:

• If output isn't captured, suppressed, or redirected, it is sent to the host (console) by default, where it is rendered based on PowerShell's rich and customizable for-display output-formatting system. See this answer for a concise overview.

• Note that the resulting representations are designed for the human observer, not for programmatic processing. While PowerShell maintains a clear separation between the actual data and its representation, the caveat is that you do end up with just the for-display, string representation in the following scenarios:

  • When you use Out-File or its effective aliases, the redirection operators > and >>
  • When you (implicitly) send output to the outside world (an outside caller's stdout stream - see below).
  • In both cases, if later programmatic processing is required, the data must be transformed into a structured text format, such as CSV (Export-Csv or ConvertTo-Csv) or JSON (using ConvertTo-Json).

As for how the outside world sees PowerShell's output streams:

• IPC (inter-process communication) at the OS level knows only two output streams: stdout (standard output) and stderr (standard error), which forces PowerShell to map its 6 output streams onto these two in order to return streaming output to an outside caller.

• While it would make sense to map PowerShell's success output stream to stdout and all other streams to stderr, unfortunately all streams are reported via stdout by default as of PowerShell 7.2 - although selectively redirecting stderr in the calling process (typically with 2>) does send PowerShell's error stream (only) to that redirection target. See the bottom section of this answer for more information.

• Also note that PowerShell as of version 7.2 only ever communicates via text (strings) with outside callers as well as with external programs called from inside a PowerShell sessions, which means that character-encoding issues can arise - see this answer for more information.

^{[1] Note that PowerShell has no concept of an input stream as such, and therefore also does not support the stdin redirection operator < familiar from other shells. Instead, commands receive streaming input (only) via the pipeline. In order to receive data from the outside world, via the PowerShell CLI's stdin stream, the automatic $input variable must be used - see this answer.}

^{[2] Using > (or >>) to redirect to a file effectively uses the Out-File cmdlet behind the scenes, and therefore its default character encoding, which is "Unicode" (UTF-16LE) in Windows PowerShell, and BOM-less UTF-8 in PowerShell (Core) 7 . However, in PowerShell version 5.1 and above you can control this encoding via the $PSDefaultParameterValues preference variable - see this answer.}

標籤：功能 电源外壳 powershell-7.0

上一篇：如果為空，輸入檔案不運行功能

下一篇：從以“NULL”作為引數的函式回傳值