Как сравнить расположение с домашней папкой в ​​PowerShell - PullRequest
1 голос
/ 16 июня 2020

Я попытался запустить сценарий в указанном c месте, но не смог и понимаю, что это связано со следующим кодом, который, как я предполагал, должен возвращать True, но на самом деле возвращает False, если вы находитесь в домашней папке в windows 10.

$loc=Get-Location 
$loc -eq $HOME  =>> Should return True but it is not.

Поэтому приветствуются любые комментарии или ответы.

Ответы [ 3 ]

4 голосов
/ 16 июня 2020

Get-Location возвращает местоположение объекта , тогда как $home - это просто строка. Преобразуйте $loc в строку или сравните $home с его свойством Path:

$loc.Path -eq $home
# or 
"$loc" -eq $home

Поскольку оператор -eq в PowerShell ведет себя в соответствии с типом левого операнда, вы также можно перевернуть два операнда, и он тоже будет работать:

$home -eq $loc
3 голосов
/ 16 июня 2020

Полезный ответ Матиаса Р. Джессена показывает, что Get-Location возвращает экземпляр System.Management.Automation.PathInfo, а не строку, и как это учесть.

Там это небольшое предостережение , однако:

Хотя это, вероятно, редко на практике, тест, основанный на свойстве .Path возвращаемого объекта и эквивалентной неявной строковой привязке всего объекта через "..." может по-прежнему терпеть неудачу, а именно, если текущее местоположение основано на настраиваемом диске PowerShell :

.Path, затем сообщает PowerShell-specifici c путь, тогда как $HOME всегда выражается как собственный путь к файловой системе , поэтому даже если два пути в конечном итоге относятся к одному и тому же расположению файловой системы, -eq не обнаружит этого.

Чтобы учесть это, используйте вместо него свойство .ProviderPath , которое, как и $HOME, выражает каталог как собственный путь файловой системы :

(Get-Location).ProviderPath -replace '[\\/]$' -eq $HOME
  • Примечание : К сожалению, необходимость f или удаление разделителя конечного пути, если он присутствует, через -replace '[\\/]$' происходит из-за того, что PowerShell, начиная с версии 7.0, не нормализует то, что сообщает .ProviderPath: если текущий, PS-диск -based путь - это root этого диска PS, .ProviderPath неожиданно сохраняет завершающий \ (или / на Unix -подобных платформах) в возвращаемом собственном пути.
    Эта проблема c поведение является предметом этого выпуска GitHub .

Чтобы дать полный пример:

# Define a custom H: drive whose root is $HOME.
$null = New-PSDrive H FileSystem $HOME

# Change to the root of the new drive, which is effectively the 
# same as $HOME, though from PowerShell's perspective the path is H:\
Set-Location H:\

# !! -> $false, because .Path reports 'H:\'
(Get-Location).Path -eq $HOME

# OK -> $true - .ProviderPath reports the true, file-system-native path.
# Note: 
#   If GitHub issue #12971 gets fixed (see above),
#   the -replace '[\\/]$' part will no longer be needed.
(Get-Location).ProviderPath -replace '[\\/]$' -eq $HOME

Дополнительно , если есть вероятность, что текущее местоположение основано на символах c точке ссылки / повторной обработки , вам придется проделать дополнительную работу, чтобы определить равенство путей.

2 голосов
/ 16 июня 2020

Get-Location возвращает объект. Вы должны сравнить $HOME с правильным свойством этого объекта:

(Get-Location).Path -eq $HOME
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...