Powershell получает значение пути из XML-файла

Question

Я новичок в PowerShell, и у меня возникают проблемы с чтением значения пути для XML-файла.

Settings.xml

<?xml version="1.0"?>
 <Configuration>
   <EmailSettings>
    <SMTPServer>blabla</SMTPServer>
    <SMTPPort>blabla</SMTPPort>
    <Path>Repository\Excel</Path>   
  </EmailSettings>
 </Configuration>

Чтобы прочитать данные в файле XML, я делаю это так

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

[xml]$ConfigFile = Get-Content "$ScriptPath\Settings.xml"

Проблема в том, что если я отображаю извлеченное значение, оно отображается правильно, а если я объединяю его с другим значением, например, чтобы получить полный путь, я получаю это

Write-Host $ScriptPath  
--> c:\script

write-host $ConfigFile.Configuration.EmailSettings.Path 
--> Repository\Excel

write-host $ScriptPath\$ConfigFile.Configuration.EmailSettings.Path   
--> c:\script\System.Xml.XmlDocument.Configuration.EmailSettings.Path

Как мы можем получить значение (в строковом формате ??), чтобы иметь возможность объединять его с другими переменными?

Спасибо

Answer 1

Вам необходим $(...), оператор подвыражения , чтобы оценить выражение , например $ConfigFile.Configuration.EmailSettings.Path внутри расширяемой строки .
Напротив, простая переменная ссылка , такая как $ScriptPath, может работать без $(...):

Write-Host "$ScriptPath\$($ConfigFile.Configuration.EmailSettings.Path)"

Обратите внимание, что я дополнительно добавил явные двойные кавычки, чтобы сделать команду более надежной - подробности см. Ниже.

В качестве отступления: Write-Host - это, как правило, неправильный инструмент для использования , если только намерение явно не записывать только на дисплей, минуя выходные потоки PowerShell.

---

Обычно без кавычек токены, которые не являются одиночными выражениями, неявно обрабатываются как расширяемые строки , т. Е. Как если бы они были переданы в двойных кавычках, и в целом применяются те же правила .

Однако, при отсутствии явного цитирования существуют дополнительные ловушки, такие как токены, начинающиеся с -, или необходимость экранирования дополнительных символов, поэтому всегда двойные кавычки расширяемых токенов хорошая привычка формироваться.

Как PowerShell анализирует токены без кавычек в режиме аргумента в целом - сложная тема - см. этот ответ .