Как получить текущий каталог выполняемого командлета

Надежный способ сделать это такой же, как вы показали $MyInvocation.MyCommand.Path.

Использование относительных путей будет основано на $ pwd в PowerShell, текущем каталоге для приложения или текущем рабочем каталоге для .NET API.

PowerShell v3 +:

Используйте автоматическую переменную $PSScriptRoot.

Да, это должно сработать. Но если вам нужно увидеть абсолютный путь, это все, что вам нужно:

(Get-Item .).FullName

Самый простой способ - использовать следующую предопределенную переменную:

 $PSScriptRoot

about_Automatic_Variables и _ 3_ оба состояния:

В PowerShell 2.0 эта переменная действительна только в модулях сценария (.psm1). Начиная с PowerShell 3.0, он действует во всех скриптах.

Я использую это так:

 $MyFileName = "data.txt"
 $filebase = Join-Path $PSScriptRoot $MyFileName

Вы также можете использовать:

(Resolve-Path .\).Path

Часть в скобках возвращает объект PathInfo.

(Доступно, начиная с PowerShell 2.0.)

Пытаться :

(Get-Location).path

or:

($pwd).path

Путь часто равен нулю. Эта функция более безопасна.

function Get-ScriptDirectory
{
    $Invocation = (Get-Variable MyInvocation -Scope 1).Value;
    if($Invocation.PSScriptRoot)
    {
        $Invocation.PSScriptRoot;
    }
    Elseif($Invocation.MyCommand.Path)
    {
        Split-Path $Invocation.MyCommand.Path
    }
    else
    {
        $Invocation.InvocationName.Substring(0,$Invocation.InvocationName.LastIndexOf("\"));
    }
}

Get-Location вернет текущий место нахождения:

$Currentlocation = Get-Location

Мне нравится однострочное решение :)

$scriptDir = Split-Path -Path $MyInvocation.MyCommand.Definition -Parent

Попробуй это:

$WorkingDir = Convert-Path .

В Powershell 3 и выше вы можете просто использовать

$PSScriptRoot

Большинство ответов не работают при отладке в следующих IDE:

• PS-ISE (PowerShell ISE)
• VS Code (код Visual Studio)

Потому что в них $PSScriptRoot пусто, а Resolve-Path .\ (и аналогичные) приведет к неправильным путям.

Ответ Freakydinde - единственный, который разрешает эти ситуации, поэтому я проголосовал за него, но не думаю, что Set-Location в этом ответе действительно то, что нужно. Я исправил это и сделал код немного понятнее:

$directorypath = if ($PSScriptRoot) { $PSScriptRoot } `
    elseif ($psise) { split-path $psise.CurrentFile.FullPath } `
    elseif ($psEditor) { split-path $psEditor.GetEditorContext().CurrentFile.Path }

Если вам просто нужно имя текущего каталога, вы можете сделать что-то вроде этого:

((Get-Location) | Get-Item).Name

Предполагая, что вы работаете из C: \ Temp \ Location \ MyWorkingDirectory>

Вывод

MyWorkingDirectory

Как бы то ни было, чтобы быть однострочным решением, приведенное ниже решение для меня является рабочим.

$currFolderName = (Get-Location).Path.Substring((Get-Location).Path.LastIndexOf("\")+1)

1 в конце - игнорировать /.

Благодаря сообщениям выше с использованием Get -Location.

эта функция установит в качестве места приглашения путь к сценарию, имея дело с другим способом получения пути к сценарию между vscode, psise и pwd:

function Set-CurrentLocation
{
    $currentPath = $PSScriptRoot                                                                                                     # AzureDevOps, Powershell
    if (!$currentPath) { $currentPath = Split-Path $pseditor.GetEditorContext().CurrentFile.Path -ErrorAction SilentlyContinue }     # VSCode
    if (!$currentPath) { $currentPath = Split-Path $psISE.CurrentFile.FullPath -ErrorAction SilentlyContinue }                       # PsISE

    if ($currentPath) { Set-Location $currentPath }
}

Можно подумать, что использование '. \' В качестве пути означает, что это путь вызова. Но не всегда. Например, если вы используете его внутри задания ScriptBlock. В этом случае он может указывать на% profile% \ Documents.

Это то, что я придумал. Это массив, включающий несколько методов поиска пути, использует текущее местоположение, отфильтровывает нулевые \ пустые результаты и возвращает первое ненулевое значение.

@((
  ($MyInvocation.MyCommand.Module.ModuleBase),
  ($PSScriptRoot),
  (Split-Path -Parent -Path $MyInvocation.MyCommand.Definition -ErrorAction SilentlyContinue),
  (Get-Location | Select-Object -ExpandProperty Path)
) | Where-Object { $_ })[0]

Чтобы расширить ответ @Cradle: вы также можете написать многоцелевую функцию, которая даст вам тот же результат по вопросу OP:

Function Get-AbsolutePath {

    [CmdletBinding()]
    Param(
        [parameter(
            Mandatory=$false,
            ValueFromPipeline=$true
        )]
        [String]$relativePath=".\"
    )

    if (Test-Path -Path $relativePath) {
        return (Get-Item -Path $relativePath).FullName -replace "\\$", ""
    } else {
        Write-Error -Message "'$relativePath' is not a valid path" -ErrorId 1 -ErrorAction Stop
    }

}

У меня были аналогичные проблемы, и это доставляло мне много проблем, поскольку я делаю программы, написанные на PowerShell (приложения с полным графическим интерфейсом пользователя), и у меня есть много файлов и ресурсов, которые мне нужно загрузить с диска. По моему опыту, использование . для представления текущего каталога ненадежно. Он должен представлять текущий рабочий каталог, но часто это не так. Похоже, что PowerShell сохраняет место, из которого PowerShell был вызван внутри .. Если быть более точным, при первом запуске PowerShell по умолчанию запускается внутри вашего домашнего каталога пользователя. Обычно это каталог вашей учетной записи, например C:\USERS\YOUR USER NAME. После этого PowerShell изменяет каталог либо на каталог, из которого вы его вызывали, либо на каталог, в котором находится сценарий, который вы выполняете, перед тем, как либо представить вам приглашение PowerShell, либо запустить сценарий. Но это происходит после того, как само приложение PowerShell изначально запускается в вашем домашнем каталоге пользователя.

А . представляет тот исходный каталог, внутри которого запускается PowerShell. Таким образом, . представляет текущий каталог только в том случае, если вы вызвали PowerShell из нужного каталога. Если позже вы измените каталог в коде PowerShell, изменения не будут отражаться внутри . во всех случаях. В некоторых случаях . представляет текущий рабочий каталог, а в других - каталог, из которого был вызван PowerShell (сам по себе, а не скрипт), что может привести к противоречивым результатам. По этой причине я использую скрипт invoker. Сценарий PowerShell с одной командой внутри: POWERSHELL. Это гарантирует, что PowerShell будет вызван из желаемого каталога и, таким образом, . будет представлять текущий каталог. Но это работает только в том случае, если вы не измените каталог позже в коде PowerShell. В случае сценария я использую сценарий invoker, который похож на последний, который я упомянул, за исключением того, что он содержит параметр файла: POWERSHELL -FILE DRIVE:\PATH\SCRIPT NAME.PS1. Это гарантирует, что PowerShell запускается внутри текущего рабочего каталога.

Простое нажатие на скрипт вызывает PowerShell из вашего домашнего каталога пользователя независимо от того, где находится скрипт. В результате текущий рабочий каталог является каталогом, в котором расположен скрипт, но каталог вызова PowerShell - C:\USERS\YOUR USER NAME, а . возвращает один из этих двух каталогов в зависимости от ситуации, что нелепо.

Но чтобы избежать всей этой суеты и использования сценария вызова, вы можете просто использовать $PWD или $PSSCRIPTROOT вместо . для представления текущего каталога в зависимости от погоды, в которой вы хотите представить текущий рабочий каталог или каталог, из которого был вызван сценарий. И если вы по какой-то причине хотите получить другой из двух каталогов, которые возвращает ., вы можете использовать $HOME.

Лично у меня просто есть скрипт вызова внутри корневого каталога моих приложений, которые я разрабатываю с помощью PowerShell, который вызывает мой основной скрипт приложения, и просто не забываю никогда не менять текущий рабочий каталог в моем исходном коде моего приложения, поэтому мне никогда не придется об этом беспокоиться, и я могу использовать . для представления текущего каталога и поддержки относительной адресации файлов в моих приложениях без каких-либо проблем. Это должно работать в более новых версиях PowerShell (новее версии 2).