如果一个函数返回多于一个值，PowerShell 会将它们封装为一个数组。然而如果您通过管道将它传递至另一个函数，该管道会自动地将数组“解封”，并且一次处理一个数组元素。

如果您需要原原本本地处理一个数组而不希望解封，那么请将返回值封装在另一个数组中。通过这种方式，管道会将外层的数组解封并处理内层的数组。

以下代码演示了这个技能：

#requires -Version 1


function Test-ArrayAsReturnValue1
{
  param($count)

  $array = 1..$count

  return $array
}

function Test-ArrayAsReturnValue2
{
  param($count)

  $array = 1..$count

  return ,$array
}

'Result 1:'
Test-ArrayAsReturnValue1 -count 10 | ForEach-Object -Process {
  $_.GetType().FullName
}

'Result 2:'
Test-ArrayAsReturnValue2 -count 10 | ForEach-Object -Process {
  $_.GetType().FullName
}

当您运行这段代码时，第一个例子将返回数组中的元素。第二个例子将会把整个数组传递给循环。

PS C:\>

Result 1:
System.Int32
System.Int32
System.Int32
System.Int32
System.Int32
System.Int32
System.Int32
System.Int32
System.Int32
System.Int32

Result 2:
System.Object[]

上个技能中我们收到一个反馈，推荐使用一个名为“Carbon”的免费 PowerShell 模块，其中包含了一大堆有用的 PowerShell 函数。

其中一个是 Get-IPAddress，它能返回您计算机的所有 IP 地址。您可以在这儿找到和下载该模块：http://get-carbon.org/。

请始终记着：从外部资源中下载 PowerShell 代码要记得检查一遍代码，确保是您所需要的内容。

PowerShell 可以用 Export-Csv 很容易创建 CSV 文件。如果您的系统中安装了 Microsoft Excel，PowerShell 可以调用 Excel 将一个 CSV 文件转换为一个 XLSX Excel 文件。

以下是一段示例代码。它使用 Get-Process 来获取一些数据，然后将数据写入一个 CSV 文件。Export-Csv 使用 -UseCulture 来确保 CSV 文件使用您所安装的 Excel 期望的分隔符。

$FileName = "$env:temp\Report"

# create some CSV data
Get-Process | Export-Csv -UseCulture -Path "$FileName.csv" -NoTypeInformation -Encoding UTF8

# load into Excel
$excel = New-Object -ComObject Excel.Application
$excel.Visible = $true
$excel.Workbooks.Open("$FileName.csv").SaveAs("$FileName.xlsx",51)
$excel.Quit()

explorer.exe "/Select,$FileName.xlsx"

下一步，Excel 打开该 CSV 文件，然后将数据保存为一个 XLSX 文件。

它工作得很好，不过可能会遇到一个类似这样的异常：

PS>  $excel.Workbooks.Open("$FileName.csv")
Exception  calling "Open" with "1" argument(s): "Old format or  invalid type library. (Exception from HRESULT: 0x80028018
(TYPE_E_INVDATAREAD))"
At line:1 char:1
+  $excel.Workbooks.Open("$FileName.csv")
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [],  MethodInvocationException
    + FullyQualifiedErrorId :  ComMethodTargetInvocation

这是一个长期已知的问题。当您的 Excel 语言和您的 Windows 操作系统不一致时可能会碰到。当您的 Windows 操作系统使用一个本地化的 MUI 包时，也许根本不会遇到这个问题。

要解决这个问题，您可以临时改变该线程的语言文化设置来适应您的 Excel 版本：

$FileName = "$env:temp\Report"

# create some CSV data
Get-Process | Export-Csv -Path "$FileName.csv" -NoTypeInformation -Encoding UTF8

# load into Excel
$excel = New-Object -ComObject Excel.Application
$excel.Visible = $true

# change thread culture
[System.Threading.Thread]::CurrentThread.CurrentCulture = 'en-US'

$excel.Workbooks.Open("$FileName.csv").SaveAs("$FileName.xlsx",51)
$excel.Quit()

explorer.exe "/Select,$FileName.xlsx"

这也会带来另外一个问题：当您以 en-US 语言文化设置运行 Excel 的 Open() 方法时，它不再需要 CSV 文件使用您的本地化分隔符。现在它需要的是一个以半角逗号分隔的文件，所以第二个脚本去掉了 -UseCulture 设置。

假设您拥有管理员权限，您可以使用一个简单的 WMI 类来检测某人是否正在通过网络访问您的资源：

PS> Get-WmiObject -Class Win32_ServerConnection |
Select-Object -Property ComputerName, ConnectionID, UserName, ShareName

这个操作也可以远程执行：只需要为 Get-WmiObject 命令增加 -ComputerName 参数即可查看谁在访问该远程计算机上的共享资源。需要拥有目标计算机的管理员权限才可以进行远程操作。

您是否厌烦了 Windows 安装了一些更新后导致的非计划中的重启？

和其它情况类似，您可以通过组策略控制重启，而且多数组策略设置只是注册表键而已。以下是一个通过设置注册表键来实现控制安装更新后的重启设置的示例脚本：

$code =
{
  $key = 'HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate\AU'
  $name = 'NoAutoRebootWithLoggedOnUsers'
  $type = 'DWord'
  $value = 1

  if (!(Test-Path -Path $key))
  {
    $null = New-Item -Path $key -Force
  }
  Set-ItemProperty -Path $key -Name $name -Value $value -Type $type
}

Start-Process -FilePath powershell.exe -ArgumentList $code -Verb runas -WorkingDirectory c:\

请注意该脚本如何操作注册表：它实际上是通过另一个 PowerShell 实例间接执行的。第二个实例是通过 Start-Process 启动的，而“-Verb Runas”确保了以管理员身份运行这段代码。

如果您当前没有管理员权限，那么会弹出提升权限的对话框供您选择使用管理员权限，或是如果您的账户没有管理员权限的时候要求您选择一个有权限的账户。

您也许知道每个 string 对象都有个 Trim() 方法可以删除该字符串开头和结尾的空白：

$text = '    Hello     '
$text.Trim()

一个鲜为人知的事实是，Trim() 也会删掉开头和结尾的换行：

$text = '

 Hello


 '
$text.Trim()

如果您需要，您可以控制 Trim() 函数吃掉的字符。

这个例子删除空格、点号、减号和换行：

$text = '

 ... Hello

 ...---
 '
$text.Trim(" .-`t`n`r")

以下是一个演示 PowerShell 如何返回一个数值型状态码给调用者的简单脚本：

$exitcode = 123

$p = Start-Process -FilePath powershell -ArgumentList "-command get-process; exit $exitcode" -PassThru
Wait-Process -Id $p.Id

'External Script ended with exit code ' + $p.ExitCode

如果您在 PowerShell 中直接调用该脚本（不使用 Start-Process），那么数值型返回值会被赋给 $LASTEXITCODE：

$exitcode = 199

powershell.exe "get-process; exit $exitcode"

'External Script ended with exit code ' + $LASTEXITCODE

如果您从一个批处理文件或是 VBScript 中运行一段 PowerShell 脚本，该数值型返回值将会赋给 %ERRORLEVEL% 环境变量，好比 PowerShell 是一个控制台应用程序一样——实际上 powershell.exe 确实是。

某些时候，我们会误会“exit”语句的工作方式。以下是一个例子：

function abc
{
  'Start'

  exit 100

  'Done'
}

abc

当您运行这个脚本时，abc 函数会被调用，然后退出。您会见到“Start”提示，但见不到“Done”提示，并且 $LASTEXITCODE 变量的值为 100。但这是实际情况吗？

当您在交互式的 PowerShell 控制台以交互式的方式运行 abc 方式时，该函数仍然退出了，不过这次，PowerShell 也被关闭了。为什么呢？

“Exit”在调用者作用域中退出代码。当您运行一个脚本时，该脚本退出后 PowerShell 仍然继续运行。当您以交互式的方式执行该函数时，交互式的 PowerShell 作为全局作用域退出了，而且由于不存在更高层的作用域了，所以 PowerShell 关闭了。

要更明显一点体现这个观点，我们在上述示例脚本中增加一点内容：

function abc
{
  'Start'

  exit 100

  'Done'
}

'Function starts'
abc
'Function ends'

如您所发现的，“exit”实际上并不是退出 abc 函数，而是退出整个脚本。所以您既见不到“Done”字样也见不到“Function ends”字样。

所以请慎用“exit”语句！它只能用在退出一个脚本并将控制权交还给调用者的时候。

您是否十分熟悉“break”、“continue”、“return”和“exit”的用法？这些是十分有用的语言概念，以下是一个演示它们不同之处的测试函数：

'Starting'

function Test-Function {
    $fishtank = 1..10

    Foreach ($fish in $fishtank)
    {
        if ($fish -eq 7)
        {
            break      # <- abort loop
            #continue  # <- skip just this iteration, but continue loop
            #return    # <- abort code, and continue in caller scope
            #exit      # <- abort code at caller scope
        }

        "fishing fish #$fish"

    }
    'Done.'
}

Test-Function


'Script done!'

只需要去掉某个关键词的注释并运行脚本，就可以观察循环的执行结果。

以下是一个查找潜在危险的 NTFS 权限的快速简单的方法。这段脚本检测所有 $pathsToCheck 的文件夹并且汇报错有具有 $dangerousBitMask 中定义的文件系统标志的安全存取控制项（译者注：也就是“路径”）。

在这个例子中，该脚本从您的 %PATH% 环境变量中得到所有查找到的路径。这些路径是高风险的，需要用 NTFS 权限来保护，只能由 Administrators 和 system 拥有写权限。

软件安装程序常常将它们自身加入环境变量而没有正确地保护它们所加入的文件夹权限。这将增加安全风险。以下脚本将检查这些地方并找出哪些有潜在危险的 NTFS 存取权限供您做决定。

# list of paths to check for dangerous NTFS permissions
$pathsToCheck = $env:Path -split ';'

# these are the bits to watch for
# if *any* one of these is set, the folder is reported
$dangerousBitsMask = '011010000000101010110'
$dangerousBits = [Convert]::ToInt64($dangerousBitsMask, 2)

# check all paths...
$pathsToCheck |
ForEach-Object {
  $path = $_
  # ...get NTFS security descriptor...
  $acl = Get-Acl -Path  $path
  # ...check for any "dangerous" access right
  $acl.Access |
  Where-Object { $_.AccessControlType -eq 'Allow' } |
  Where-Object { ($_.FileSystemRights -band $dangerousBits) -ne 0 } |
  ForEach-Object {
    # ...append path information, and display filesystem rights as bitmask
    $ace = $_
    $bitmask = ('0' * 64) + [Convert]::toString([int]$ace.FileSystemRights, 2)
    $bitmask = $bitmask.Substring($bitmask.length - 64)
    $ace | Add-Member -MemberType NoteProperty -Name Path -Value $path -PassThru | Add-Member -MemberType NoteProperty -Name Rights -Value $bitmask -PassThru
  }
} |
Sort-Object -Property IdentityReference |
Select-Object -Property IdentityReference, Path, Rights, FileSystemRights |
Out-GridView