如何获取 PowerShell 脚本的当前位置

  1. 使用 Split-Path Cmdlet 获取 PowerShell 脚本的当前所在位置
  2. 使用 $PSScriptRoot 变量获取 PowerShell 脚本的当前所在位置
  3. 在 Windows PowerShell 中获取当前工作目录以获取 PowerShell 脚本的当前所在位置
  4. 结论
如何获取 PowerShell 脚本的当前位置

在这本综合指南中,我们深入探讨了多种方法来确定 PowerShell 脚本的当前所在位置,这是增强脚本可移植性和可靠性的基本方面。讨论的每种方法都适用于不同版本的 PowerShell 和脚本场景,确保了广泛的适用性。

我们首先使用 Split-Path cmdlet,这是早期 PowerShell 版本的一种多功能方法,然后过渡到 PowerShell 3 及更高版本中 $PSScriptRoot 的便利性。此外,我们还探讨了强大的 $ExecutionContext 方法和简单的 Get-Location cmdlet,以满足不同环境和要求。

最后,我们通过熟悉的 pwd 别名简化了这个过程,展示了 PowerShell 的适应性。

使用 Split-Path Cmdlet 获取 PowerShell 脚本的当前所在位置

在 PowerShell 3 之前,使用 Split-Path cmdlet 查询 MyInvocation.MyCommand.Definition 属性没有更好的方法。

使用 Split-Path$global:MyInvocation 的主要目的是提取当前正在执行的 PowerShell 脚本的目录路径。当脚本需要与同一位置的其他文件或目录交互,或脚本的行为依赖于其位置时,这一点特别有用。

$scriptDirectory = Split-Path -Parent $MyInvocation.MyCommand.Definition
Write-Host "Current script location: $scriptDirectory"

在这个示例中,我们使用 Split-Path-Parent 参数来从正在运行的脚本的完整路径中隔离目录组件。此路径是从 $MyInvocation.MyCommand.Definition 中获取的。

结果目录路径存储在变量 $scriptDirectory 中。

最后,我们使用 Write-Host 输出此目录路径,提供脚本当前所在位置的清晰而直接的视图。这种方法不仅高效,而且确保了与不同版本的 PowerShell 的兼容性。

输出:

获取 PowerShell 脚本的当前路径 - 输出 1

值得注意的是,只有在已保存的 PowerShell (.ps1) 文件中包含上述语法时,该方法才有效。在命令行中运行上述语法将返回 Null 异常。

同样值得注意的是,在 PowerShell 的集成脚本环境 (ISE) 中选择运行上述语法 (作为选择运行或按 F8) 将触发 ParameterArgumentValidationErrorNullNotAllowed 或 Null 异常。

解决此问题的一个简单方法是调用 $psISE 变量并获取 CurrentFile.FullPath 属性,从那里可以获取脚本的当前所在位置。

使用 $PSScriptRoot 变量获取 PowerShell 脚本的当前所在位置

如果您正在运行 PowerShell 版本 3 或更高版本,则引入了一个自动变量来存储当前文件或模块的目录。

$PSScriptRoot 变量保存正在执行的脚本的目录路径。这个自动变量对于创建可移植脚本非常有用,因为硬编码路径并不实际。

当您的脚本需要加载与脚本本身位于同一目录中的文件或模块时,它尤其方便。

Write-Host "The current script is located in: $PSScriptRoot"

在我们的脚本中,我们使用 Write-Host cmdlet 打印 $PSScriptRoot 的值。这个变量自动包含脚本所在目录的完整路径。

通过调用 Write-Host,我们确保路径在 PowerShell 控制台中显示。这种方法既简单又有效,使脚本在各种环境和场景中都具有通用性。

输出:

获取 PowerShell 脚本的当前位置信息 - 输出 2

在 Windows PowerShell 中获取当前工作目录以获取 PowerShell 脚本的当前所在位置

现在我们已经讨论了如何获取脚本的当前位置,学习如何获取脚本的当前工作目录也是有益的。

在 Windows PowerShell v2 中,$ExecutionContext 变量包含 EngineIntrinsics 属性。您可以使用这个变量和属性找到可用的 cmdlet 执行对象,包括正在运行的 Windows PowerShell 脚本的当前工作目录。

$currentScriptLocation = $ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath('.\')
Write-Host "Current script location: $currentScriptLocation"

在这个示例中,我们利用 $ExecutionContext 获取当前脚本的位置。通过调用 GetUnresolvedProviderPathFromPSPath 方法并使用参数 '.\',我们有效地请求 PowerShell 将当前目录(由 '.\' 表示)转换为完整路径。

结果存储在变量 $currentScriptLocation 中,我们随后通过 Write-Host 显示。该方法特别稳健,因为它不依赖于脚本以特定方式运行,并且适用于不同版本的 PowerShell。

输出:

获取 PowerShell 脚本的当前位置 - 输出 3

然而,如果您正在运行最新版本的 Windows PowerShell,则引入了一个单独的 cmdlet 以方便操作。我们可以使用 Get-Location cmdlet 并调用 Path 属性来获取脚本的当前工作目录。

$currentDirectory = (Get-Location).Path
Write-Host "Current directory: $currentDirectory"

在提供的代码中,我们首先使用 Get-Location cmdlet 获取当前位置信息对象。然后我们访问其 Path 属性以获取当前目录的字符串,并将其存储在 $currentDirectory 变量中。

最后,我们使用 Write-Host 显示此信息。这种方法对于需要知道其目录位置的执行上下文的脚本非常有效。

输出:

获取 PowerShell 脚本的当前位置 - 输出 4

在 PowerShell 中,pwdGet-Location cmdlet 的别名。Get-Location cmdlet 检索 PowerShell 会话的当前工作目录,这正是传统的 pwd(打印工作目录)命令在类 Unix 系统中所做的。

考虑到 PowerShell 的灵活性和兼容性,它提供了这些别名,以便让熟悉其他 shell 环境(如 Unix 或 Linux)的用户更容易在 PowerShell 中使用类似的命令。

$currentDirectory = pwd
Write-Host "Current directory: $currentDirectory"

在这个示例中,我们使用 pwd 命令获取当前位置信息对象,然后将其存储在 $currentDirectory 变量中。利用 Write-Host,我们将当前目录的路径输出到控制台。

这种方法显得特别简单,不需要任何复杂的语法或额外的参数。这是一种快速且可靠的方法来确定脚本运行时的目录。

输出:

获取 PowerShell 脚本的当前位置信息 - 输出 5

结论

本文对各种方法进行了全面探索,以确定 PowerShell 脚本的当前所在位置,每种方法都针对不同的 PowerShell 版本和脚本上下文进行了量身定制。从适用于早期版本的 Split-Path cmdlet 到适用于较高版本的自动 $PSScriptRoot 变量,本指南确保了对广泛范围的 PowerShell 用户的相关性。

此外,使用 $ExecutionContextGet-Location cmdlet 各自提供了强大和直接的替代方案,而 pwd 别名则为来自不同脚本背景的用户提供了一个熟悉的选择。这本全面的指南不仅增强了脚本的可移植性和可靠性,还有力地突显了 PowerShell 的多功能特性。

掌握这些技术后,脚本编写者和系统管理员将更好地处理文件路径依赖,使他们的脚本在各种环境中更加适应和有效。最终,理解这些方法对掌握 PowerShell 脚本和优化跨不同平台和场景的脚本功能至关重要。

Enjoying our tutorials? Subscribe to DelftStack on YouTube to support us in creating more high-quality video guides. Subscribe
Marion Paul Kenneth Mendoza avatar Marion Paul Kenneth Mendoza avatar

Marion specializes in anything Microsoft-related and always tries to work and apply code in an IT infrastructure.

LinkedIn