Powershell экранирование символов – Кавычки в PowerShell

Кавычки в PowerShell

Строковые значения в PowerShell встречаются довольно часто. Как правило, они передаются командам как аргументы. Иногда строки заключаются в двойные или одинарные кавычки, а иногда обходятся без них. Неправильно поставленные (или не поставленные) кавычки являются причиной множества ошибок в коде, поэтому очень важно помнить правила работы с кавычками: когда текст нужно заключать в кавычки, когда нет и когда какой тип кавычек лучше использовать.

Для начала посмотрим, что дает нам использование кавычек. В качестве примера назначим переменной $a значение 123 и выведем ее тип данных:

$a = 123
$a.GetType()

Затем сделаем то же самое, только значение переменной заключим в кавычки:

$a = ″123″
$a.GetType()

В первом случае переменная имеет тип данных Int32 (32-разрядное число), а во втором String (строка).

Из примера видно, что наличие кавычек однозначно указывает на то, что объект имеет тип String. Другими словами, когда текст заключается в кавычки, PowerShell рассматривает его как строку.

Надо сказать, что PowerShell и сам умеет определять тип данных. Так если значение состоит из одних цифр, то объект определяется как числовой, если же в значении содержится хотя бы одна буква, то PowerShell определяет объект как строку, вне зависимости от наличия\отсутствия кавычек.

В большинстве случаев кавычки можно не ставить, если аргумент представляет из себя строку без пробелов. Для примера сменим текущую директорию командой:

Set-Location C:\Windows

Хотя путь к директории указан без кавычек, тем не менее команда успешно выполнена. А вот такая команда обязательно вызовет ошибку:

Дело в том, что для интерпретатора пробел означает завершение команды, поэтому следующее за пробелом слово and определяется как параметр. Поскольку параметра с таким именем у командлета Set-Location нет, генерируется ошибка. Проблема решается просто, достаточно путь заключить в кавычки, например так:

Set-Location ′C:\Documents and Settings′

С назначением кавычек более-менее разобрались, переходим к их типам.

В PowerShell можно использовать два типа кавычек —  одинарные и двойные. В большинстве случаев не важно, какой тип использовать. Для примера возьмем две переменных и присвоим им одинаковое значение. У переменной $a значение поместим в двойные кавычки, а у $b в одинарные:

$a = ″Текст в кавычках″
$b = ′Текст в кавычках′

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

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

В тексте содержится переменная

Если в строку, заключенную в кавычки, надо вставить значение переменной, то необходимо использовать двойные кавычки. При использовании одинарных кавычек все, что находится внутри кавычек  обрабатывается как тест, вне зависимости от содержимого. Только при наличии двойных кавычек PowerShell ищет внутри текста знак $ и подставляет вместо имени переменной ее значение. Например:

$c = ′строка′
$a = ″$c в кавычках″
$b = ′$c в кавычках′

Если теперь вывести значения переменных $a и $b, то в первом случае будет выведено значение переменной, а во втором ее имя.

Добавление специальных символов

Только двойные кавычки дают возможность использовать специальные символы внутри текста. В тексте, ограниченном двойными кавычками, PowerShell ищет управляющий символ — обратную одинарную кавычку (`)  и выполняет следующий за ней спец. символ.

Примечание. Вывести список спец. символов можно командой Get-Help about_special_characters.

В качестве примера попробуем отформатировать текст, вставив в него символ n (перенос строки):

$a = ″`n Строка 1 `n Строка 2 `n Строка 3 `n″
$a = ′`n Строка 1 `n Строка 2 `n Строка 3 `n′

Как видите, спец.символы в двойных кавычках обработаны правильно, а в одинарных просто выведены на экран.

Кавычки в кавычках

Иногда может потребоваться выделить текст внутри кавычек. Но использовать один тип кавычек дважды не получится, например при попытке создать переменную мы получим ошибку:

$a = ′Кавычки ′внутри′ кавычек′

а командлет Write-Output не выдаст ошибку, но добавит после первой пары кавычек перенос строки:

Write-Output ′Кавычки ′внутри′ кавычек′

Поэтому, если нужно использовать кавычки в строке, то придется их комбинировать — добавлять двойные кавычки внутри одинарных или одинарные внутри двойных:

$a = ′Кавычки ″внутри″ кавычек′
$b = ″Кавычки ′внутри′ кавычек″

При работе с переменными надо помнить, что для PowerShell значение имеет только внешняя пара кавычек. Например так мы получим только имя переменной:

$c = ′внутри′
$a = ′Кавычки ″$c″ кавычек′

а вот так ее значение:

$a = ″Кавычки ′$c′ кавычек″

И еще, говоря о кавычках, стоит упомянуть о такой вещи как экранирование. Специальный символ (кавычка, знак $ и пр.), следующий за обратной кавычкой (`), экранируется — воспринимается не как специальный, а как обычный строковый символ. Поэтому при использовании кавычек внутри кавычек внутреннюю пару кавычек можно экранировать:

$a = ″Кавычки `″внутри`″ кавычек″

Тогда они будут выведены как обычный текст.

Экранирование работает только с двойными кавычками. При попытке экранировать символы в строке, заключенные в одинарные кавычки, управляющий символ никак не повлияет на исходные данные.

windowsnotes.ru

Power Shell. Урок 4. Как правильно использовать кавычки при работе со строковыми значениями | Windows IT Pro/RE

Работа со строковыми значениями

Всякий раз, когда текст заключается в кавычки, PowerShell рассматривает его как строковое значение. Поэтому, если только текст не содержит специальных символов (ими мы займемся очень скоро) или переменных ссылочного типа (речь о таких переменных пойдет на следующем уроке), такой текст можно заключать в одинарные либо в двойные кавычки. Так, следующие инструкции дают идентичные результаты:

Write-Output «String in quotes.»
Write-Output ‘String in quotes.’

В приведенных примерах команда Write-Output направляет строковый объект в конвейер, а в данном случае — непосредственно на консоль PowerShell. Как показано на экране 1, обе инструкции имеют одно и то же выходное значение.

Чтобы вывести данные на консоль, можно использовать не только Write-Output, но и реализованные в PowerShell команды Out-Host, а также Write-Host. Различия между ними в деталях. Так, команда Write-Output направляет выходные данные по конвейеру следующей команде. Когда же Write-Output является последней командой в конвейере, ее выходные данные отображаются в консоли. Команда Out-Host направляет свои выходные данные непосредственно на консоль. Она имеет необязательный параметр, который позволяет просматривать выходные данные поэкранно, что полезно при больших объемах выходных данных. Out-Host используется в качестве выходной команды по умолчанию, поэтому если вы не указываете, какая команда является выходной, применяется именно она. Команда Write-Host тоже направляет выходные данные непосредственно на консоль. Но она имеет два необязательных параметра, которые дают возможность изменять цвет текста или фона, на котором отображается текст, что позволяет настраивать консоль в соответствии с пожеланиями пользователя.

При использовании заключенных в кавычки базовых строковых значений, которые передаются непосредственно в окно консоли, все три команды ведут себя одинаково. К примеру, все четыре публикуемые ниже команды отображают строку в окне консоли так, как показано на экране 1:

«String in quotes.»
Write-Output «String in quotes.»
Write-Host «String in quotes.»
Out-Host ` – InputObject «String in quotes».

Обратите внимание: в первой команде глагол не указан. В результате используется команда Out-Host.

Надо сказать, что во многих приводимых в статье примерах я использую команду Write-Output, поскольку она работает с выходным объектом так же, как и многие другие команды. Так я получаю возможность продемонстрировать различные принципы, применяемые в отношении заключенных в кавычки значений. Впрочем, не следует забывать, что команды Write-Output, Out-Host и Write-Host в разных обстоятельствах могут вести себя по-разному. Дополнительные сведения об этих командах можно найти в справочных файлах.

Если вы хотите использовать кавычки внутри строки, можете вводить одинарные кавычки внутри двойных или двойные кавычки внутри одинарных:

Write-Output «String ‘in’ quotes.»
Write-Output ‘String «in» quotes.’

Вернемся к экрану 1. Обратите внимание, что в обоих случаях в выходных данных отображаются внутренние кавычки. Иные результаты получаются, если в строке используются кавычки только одного типа:

Write-Output «String «in» quotes.»
Write-Output ‘String ‘in’ quotes.’

В обоих случаях кавычки не отображаются, и добавляется новая строка. Дело в том, что PowerShell интерпретирует эту одну строку как несколько строк и, соответственно, добавляет символ переноса строки. Так, PowerShell истолковывает String как первую строку (и потому добавляет после нее символ переноса строки), а затем интерпретирует оставшуюся часть текста как отдельную строку. Вы можете использовать двойные кавычки внутри двойных кавычек, но внутренние кавычки при этом придется экранировать (о том, как это делается, я расскажу позже).

Итак, при работе с кавычками всегда будьте внимательны и не путайте тип используемых кавычек (а также не забывайте включать кавычки того или иного типа). Иначе можно оказаться внутри цикла: система предлагает ввести некое значение, но что бы вы ни вводили, цикл не прерывается. Кстати, если вы попадете в такую ситуацию, нажмите сочетание клавиш Ctrl+C, и вы вернетесь к приглашению командной строки.

При определении аргументов команды нужно иметь в виду еще одно обстоятельство, а именно: каким образом оболочка PowerShell трактует численные значения. Как я уже говорил, все заключенные в кавычки значения PowerShell рассматривает как строки — даже если значения состоят из одних только чисел.

Write-Output «123»

Когда выполняется эта инструкция (показанная на экране 2), возвращаемое значение является строковым объектом. Тип этого значения можно проверить, выполнив инструкцию 

(Write-Output «123»).GetType ()

В данной инструкции используется метод типа объекта GetType, который в нашем случае является типом String, а точнее — System.String (что тоже показано на экране 2). Дополнительные сведения о System.String и GetType приведены во врезке «Получение и использование членов объектов System.String».

Если численное значение не заключается в кавычки, PowerShell рассматривает его как числовой объект. Так, следующая инструкция возвращает целочисленный объект:

Write-Output 123

И в этом случае тип объекта можно проверить с помощью метода GetType:

(Write-Output 123).GetType ()

Как видно на экране 2, объект принадлежит типу Int32.

Если значение включает в себя как цифры, так и буквы, PowerShell рассматривает его как строку вне зависимости от наличия или отсутствия кавычек. Так, следующая инструкция возвращает строку, что подтверждается при выполнении второй инструкции:

Write-Output 123 output
(Write-Output 123 output).GetType ()

И вновь выходные данные этих инструкций мы можем увидеть на экране 2.

В большинстве случаев кавычки можно опускать, если аргумент представляет собой строку, не содержащую пробелов. В трех следующих инструкциях команда Set-Location используется для того, чтобы указать в качестве рабочей папки накопитель C.

Set-Location C:
Set-Location «C:»
Set-Location ‘C:’

А теперь представим себе, что в качестве рабочей нужно указать новую папку — C:Documents and Settings:

Set-Location `
C:Documents and Settings

Эта инструкция завершается ошибкой, поскольку программа не знает, что делать с маркерами (словами), следующими после первого пробела. Как явствует из экрана 3, анализатор рассматривает слово «and» как параметр, а поскольку параметра с таким именем не существует, анализатор генерирует ошибку. Проблема решается легко — весь аргумент необходимо заключить в кавычки:

Set-Location `
«C:Documents and Settings»

Теперь при выполнении данной инструкции меняется рабочая папка, как показано на экране 3.

Еще один важный вопрос состоит в том, как нужно ссылаться на переменные, которые содержатся в заключенной в кавычки строке. Если строка заключена в двойные кавычки, используется значение переменной. Если же строка заключена в одинарные кавычки, применяется значение литерала. Как я уже отмечал, о переменных, а также о способах ссылки на переменные в строках речь пойдет в следующей статье. Впрочем, если вы хотите уже сейчас получить дополнительную информацию об использовании переменных в строках, обратитесь к справочному файлу about_quoting_rules.

Экранирование специальных символов в строках

В приведенных выше примерах использовались аргументы, которые можно заключать как в одинарные, так и в двойные кавычки. В результате у читателей может сложиться впечатление, будто между двумя типами кавычек нет никаких различий. Однако различие есть, причем весьма важное: одинарные кавычки всегда представляют строку как литерал, тогда как двойные кавычки дают возможность экранировать специальные символы внутри текста. Специальный символ — это такой символ, который, если следует после обратной кавычки (`), предписывает программе предпринять то или иное действие; если же перед специальным символом обратной кавычки нет, упомянутое действие не совершается. В таблице приведен перечень специальных символов оболочки PowerShell.

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

Write-Output («`n`tText includes» + ` «`n`t`»escaped`» characters.`n»)

Первый экранированный символ (следующий за первой обратной кавычкой) — это литера n; в данном контексте она предписывает вставить новую строку. Второй экранированный символ — t; он вставляет знак табуляции. Отметим, что обратная кавычка в конце первой строки рассматривается не как символ экранирования, а как символ продолжения (см. урок 2). Во второй строке символы `n и `t используются еще несколько раз. Кроме того, обратные кавычки предваряют двойные кавычки, обрамляющие слово escaped. В результате эти двойные кавычки отображаются в выходных данных. Взглянув на экран 4, вы увидите, как отображаются новые строки, знаки табуляции и двойные кавычки. Дополнительные сведения об экранировании символов можно найти в справочном файле about_escape_character.

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

Write-Output ‘`tindented`n`twords’

возвратит строку в точности в той же форме, в какой она была введена (см. экран 4). Отметим, кстати, что в предварительных выпусках PowerShell пользователь мог экранировать символы внутри строк, заключенных в одинарные кавычки, и оболочка корректно анализировала их. Так что вам могут встретиться материалы, в которых утверждается, будто PowerShell именно таким образом обрабатывает строки в одинарных кавычках.

На следующих уроках

В большинстве случаев строковые значения играют важную роль в формировании инструкций PowerShell. И чем лучше вы понимаете, как работать со строками, тем больше пользы принесут создаваемые вами инструкции. Рекомендую читателям не жалеть времени на изучение различных методов использования строк. Попробуйте заключить строку в одинарные и в двойные кавычки, а затем постарайтесь выполнить команды без кавычек. И не забывайте осваивать метод экранирования специальных символов.

Роберт Шелдон ([email protected]) — технический консультант и автор большого количества книг по технологиям Microsoft Windows и базам данных

Пoлучение и использование членов объектов System.String

болочка PowerShell рассматривает все строки как объекты System.String. Это значит, что в распоряжение пользователя поступает богатый набор методов и свойств данных объектов. Как было показано в уроке 3, команда Get-Member считывает члены объекта в то время, когда объект передается по конвейеру. Поскольку строка передается в виде объекта, для этой строки можно использовать команду Get-Member. К примеру, следующая инструкция считывает членов объекта для строки test output:

«test output» | Get-Member

Как показано на экране A, строковый объект поддерживает большое число методов, включая Substring и GetType. Если бы мы продолжили просмотр отображенного на экране списка, то обнаружили бы свойство Length, которое отражает число символов в строке.

Теперь представим себе, что нам нужно получить дополнительную информацию о методе Substring объекта System.String. Опять-таки мы можем получить нужные сведения с помощью команды Get-Member. Достаточно указать метод Substring в качестве аргумента Get-Member и далее передать полученные результаты по конвейеру команде Format-List

«test output» |
Get-Member Substring |
Format-List

На экране B показан результат выполнения этой инструкции. Обратите внимание на то, что определение включает детали процедуры использования метода. Это синтаксис данного метода. Синтаксис указывает, что при вызове метода мы можем придерживаться одного из двух подходов. Вот они:

System.String Substring (Int32 startIndex)
System.String Substring (Int32 startIndex, Int32 length)

Первый подход предполагает указание пользователем целевой строки и позиции, с которой должна начинаться подстрока. Этот метод возвращает подстроку, которая начинается с указанной позиции и завершается в конце строки. Например, если целевая строка — test output, и нам нужно возвратить подстроку, которая начинается с позиции 5, мы используем инструкцию

(«test output»).Substring (5)

которая возвратит подстроку output. Как показывает эта инструкция, целевую строку необходимо заключить в скобки, поставить точку, а затем указать имя метода и параметры, опять-таки заключенные в скобки.

При использовании второго подхода пользователь указывает целевую строку, а также стартовую позицию и длину подстроки. Допустим, нам нужно возвратить подстроку, которая начинается в начале строки (позиция 0) и имеет длину в четыре символа. Итак, создаем инструкцию

(«test output»).Substring (0,4)

и она возвращает нам подстроку test.

Когда пользователь вызывает метод, например, Substring или GetType, этот метод создает собственный объект, который может быть передан по конвейеру. В результате пользователь может с помощью команды Get-Member получать список этих членов объекта. К примеру, метод GetType возвращает объект System.RuntimeType, а этот объект поддерживает многочисленные методы и свойства. Следующая инструкция возвращает список свойств, которыми располагает объект System.RuntimeType:

(«test output»).GetType () |
Get-Member -MemberType Property

Как показывает инструкция, сначала нужно заключить строку в скобки, добавить точку и затем ввести имя метода — в данном случае это GetType. Затем объект, возвращаемый методом GetType, передается по конвейеру команде Get-Member. Обратите внимание: я использовал параметр MemberType для того, чтобы отобразить только возвращенные параметры объекта. Результаты представлены на экране С.

Power Shell. Урок 4. Как правильно использовать кавычки при работе со строковыми значениями

Поделитесь материалом с коллегами и друзьями

www.osp.ru

Как экранировать содержимое динамической переменной в PowerShell?

ТЛ; др

• Ваша команда должна работать — кроме случаев, когда $password содержит символы «.

  • Напротив, $ chars. Не должно быть проблемой.

• Ваш метод /pass:"`"$password`"" , т. Е. Явные встроенные двойные кавычки, также правильно обрабатывает значения со встроенными пробелами , в отличие от метода /pass:$password (также), предложенного в полезном ответе Билла Стюарта .

  • Вы можете упростить команду, опуская внешнюю кавычку "..." , как это также предлагается в ответе Билла:
    /pass:`"$password`"

• Что касается поддержки " chars. В значениях: даже \ -экранирование их не всегда работает, а именно, когда также используются пробелы — см. Подробности ниже.

Проблема в том, что он ломается, когда пароль содержит символ $.

Ваша команда передает любые символы $ встроенные в значение $password в целевую программу как есть.

Поэтому, если есть проблема, подразумевается, что ваша целевая программа — cmdkey.exe — интерпретирует символы $ , но обратите внимание, что документы не упоминают об этом.
Однако, если это действительно так, вам придется экранировать символы $ как того требует целевая программа , чтобы передать их буквально.

Предостережение: есть фундаментальное ограничение , однако:

Команды обычно ломаются, если значение аргумента содержит пробелы И встроенные символы , независимо от того, правильно ли они экранированы для целевой программы или нет.

Как правило, вы бы избегали value-internal " as \" чтобы не разрывать заключенную в кавычки значение:

# !! Only works if:
# !!  * $password contains NO "
# !!  * $password contains " but NOT ALSO SPACES
# !!  * $password contains PAIRS of " and what is between each
# !!    pair does not contain spaces
cmdkey.exe /add:$hostname /user:"$user" /pass:`"$($password -replace '"', '\"')`"

<sup>Замечания:
* Выход из встроенного " как \" не является стандартом как таковым, но он признается большинством внешних программ;единственные заметные исключения — командные файлы — подробности смотрите в этом ответе .
* Возможно, PowerShell должен обрабатывать это экранирование автоматически — подробности смотрите в этом выпуске GitHub .</sup>

Если Windows PowerShell считает, что она не может передать полученный токен как есть в качестве одного аргумента целевой программе, она слепо применяет двойные кавычки вокруг всего токена ^[1] , что в сочетании с экранированным символом может привести к неверному синтаксису :

Например, если $password буквально содержит a " b , PowerShell заканчивает тем, что пропускает следующее за кулисами, используя команду выше:

 ...  "/pass:"a \" b""

То есть результирующий буквенный токен, который видел PowerShell — /pass:"a \" b" — был слепо заключен в двойные кавычки , в целом , даже если большинство целевых программ будет правильно анализировать /pass:"a \" b" как -является.
В результате явно предоставленная двойная кавычка становится недействительной (так как для этого потребуется другой уровень экранирования) — и если не использовать --% , символ остановки анализа, который затем ограничивает вас литералами (или %...% -стильные ссылки на переменные окружения), пути к этому нет.

Если целевая программа распознает аргумент, если он заключен в двойные кавычки в целом (например,
"/pass:ab" вместо /pass:"ab" ), вы можете опустить явные двойные кавычки вокруг значения аргумента.
Однако обратите внимание, что некоторые целевые программы, включая cmdkey.exe , не распознают аргумент, если он заключен в двойные кавычки в целом.

... /pass:$($password -replace '"', '\"')

С $password буквально содержащим a " b , PowerShell затем проходит за кулисы:

... "/pass:a \" b"

Это синтаксически допустимо — для целевых программ, которые распознают \" как экранированный " , что является нормой — но, как уже говорилось, тот факт, что весь аргумент заключен в «» … «, а не только значение, может не поддерживаться целевой программой.

^{[1] Windows PowerShell игнорирует все \ -экранирование в результирующем токене и считает, что все встроенные " имеют синтаксическую функцию: с этой точки зрения, если токен не состоит из какого-либо соединения строк, соединенных в кавычки и заключенных в двойные кавычки, включая двойные Цитирование применяется вслепую — что может нарушить команду.
Такое поведение не только неясно, оно предотвращает надежную и предсказуемую передачу параметров.
Ядро PowerShell теперь распознает \" как экранированные; однако цитаты, которые не экранированы как \" прежнему приводят к неправильным кавычкам;например, 'a "bc" d' передается как "a "bc" d" , которые целевые программы анализируют как 2 аргумента, ab и cd (после удаления кавычек).}

geekquestion.com

Кавычки в PowerShell

Кавычки в PowerShell

Строковые значения в PowerShell встречаются довольно часто. Как правило, они передаются командам как аргументы. Иногда строки заключаются в двойные или одинарные кавычки, а иногда обходятся без них. Неправильно поставленные (или не поставленные) кавычки являются причиной множества ошибок в коде, поэтому очень важно помнить правила работы с кавычками: когда текст нужно заключать в кавычки, когда нет и когда какой тип кавычек лучше использовать.

Для начала посмотрим, что дает нам использование кавычек. В качестве примера назначим переменной $a значение 123 и выведем ее тип данных:

$a = 123
$a.GetType()

Затем сделаем то же самое, только значение переменной заключим в кавычки:

$a = ″123″
$a.GetType()

В первом случае переменная имеет тип данных Int32 (32-разрядное число), а во втором String (строка).

Из примера видно, что наличие кавычек однозначно указывает на то, что объект имеет тип String. Другими словами, когда текст заключается в кавычки, PowerShell рассматривает его как строку.

Надо сказать, что PowerShell и сам умеет определять тип данных. Так если значение состоит из одних цифр, то объект определяется как числовой, если же в значении содержится хотя бы одна буква, то PowerShell определяет объект как строку, вне зависимости от наличия\отсутствия кавычек.

В большинстве случаев кавычки можно не ставить, если аргумент представляет из себя строку без пробелов. Для примера сменим текущую директорию командой:

Set-Location C:\Windows

Хотя путь к директории указан без кавычек, тем не менее команда успешно выполнена. А вот такая команда обязательно вызовет ошибку:

Set-Location C:\Documents and Settings

Дело в том, что для интерпретатора пробел означает завершение команды, поэтому следующее за пробелом слово and определяется как параметр. Поскольку параметра с таким именем у командлета Set-Location нет, генерируется ошибка. Проблема решается просто, достаточно путь заключить в кавычки, например так:

Set-Location ′C:\Documents and Settings′

С назначением кавычек более-менее разобрались, переходим к их типам.

В PowerShell можно использовать два типа кавычек —  одинарные и двойные. В большинстве случаев не важно, какой тип использовать. Для примера возьмем две переменных и присвоим им одинаковое значение. У переменной $a значение поместим в двойные кавычки, а у $b в одинарные:

$a = ″Текст в кавычках″
$b = ′Текст в кавычках′

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

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

В тексте содержится переменная

Если в строку, заключенную в кавычки, надо вставить значение переменной, то необходимо использовать двойные кавычки. При использовании одинарных кавычек все, что находится внутри кавычек  обрабатывается как тест, вне зависимости от содержимого. Только при наличии двойных кавычек PowerShell ищет внутри текста знак $ и подставляет вместо имени переменной ее значение. Например:

$c = ′строка′
$a = ″$c в кавычках″
$b = ′$c в кавычках′

Если теперь вывести значения переменных $a и $b, то в первом случае будет выведено значение переменной, а во втором ее имя.

Добавление специальных символов

Только двойные кавычки дают возможность использовать специальные символы внутри текста. В тексте, ограниченном двойными кавычками, PowerShell ищет управляющий символ — обратную одинарную кавычку (`)  и выполняет следующий за ней спец. символ.

Примечание. Вывести список спец. символов можно командой Get-Help about_special_characters.

В качестве примера попробуем отформатировать текст, вставив в него символ n (перенос строки):

$a = ″`n Строка 1 `n Строка 2 `n Строка 3 `n″
$a = ′`n Строка 1 `n Строка 2 `n Строка 3 `n′

Как видите, спец.символы в двойных кавычках обработаны правильно, а в одинарных просто выведены на экран.

Кавычки в кавычках

Иногда может потребоваться выделить текст внутри кавычек. Но использовать один тип кавычек дважды не получится, например при попытке создать переменную мы получим ошибку:

$a = ′Кавычки ′внутри′ кавычек′

а командлет Write-Output не выдаст ошибку, но добавит после первой пары кавычек перенос строки:

Write-Output ′Кавычки ′внутри′ кавычек′

Поэтому, если нужно использовать кавычки в строке, то придется их комбинировать — добавлять двойные кавычки внутри одинарных или одинарные внутри двойных:

$a = ′Кавычки ″внутри″ кавычек′
$b = ″Кавычки ′внутри′ кавычек″

При работе с переменными надо помнить, что для PowerShell значение имеет только внешняя пара кавычек. Например так мы получим только имя переменной:

$c = ′внутри′
$a = ′Кавычки ″$c″ кавычек′

а вот так ее значение:

$a = ″Кавычки ′$c′ кавычек″

И еще, говоря о кавычках, стоит упомянуть о такой вещи как экранирование. Специальный символ (кавычка, знак $ и пр.), следующий за обратной кавычкой (`), экранируется — воспринимается не как специальный, а как обычный строковый символ. Поэтому при использовании кавычек внутри кавычек внутреннюю пару кавычек можно экранировать:

$a = ″Кавычки `″внутри`″ кавычек″

Тогда они будут выведены как обычный текст.

Экранирование работает только с двойными кавычками. При попытке экранировать символы в строке, заключенные в одинарные кавычки, управляющий символ никак не повлияет на исходные данные.

webhamster.ru

Функция для экранирования символов в путях

Есть ли в PowerShell функция для экранирования символов в путях?

Примечание: я знаю, что большинство командлетов, которые предоставляют Pathпараметр, также предоставляют LiteralPathпараметр, который решает эту проблему. Этот вопрос скорее из любопытства, чем из-за необходимости, так как в большинстве случаев, о которых я могу подумать, переключение на LiteralPathимеет смысл. Однако существуют некоторые подлинные варианты использования (например, Start-BitsTransferимеет Sourceпараметр, но не имеет буквального эквивалента).

подробность

Если у меня есть файл c:\temp\test[0123].txt, вместо этого Get-Item 'c:\temp\test[0123].txt'я должен был бы использовать, Get-Item 'c:\temp\test`[0123`].txt'чтобы получить результат (или использовать LiteralPathпараметр).

Даже путь, возвращенный другой командой PowerShell, возвращает неэкранированную строку; то есть Get-ChildItem 'c:\temp\' -Filter 'test*.txt' | Convert-Path | Get-Itemне удается (примечание: если мы передадим фактический FileSystemInfoобъект, все работает, но этот объект не имеет свойств с правильно экранированным путем строки).

Мы можем легко избежать этого, используя следующий код:

$path = 'c:\temp\test[0123].txt'
$path = $path -replace '([][[])', '`$1' # escape square brackets by adding back ticks
Get-Item $path

Однако при экранировании строк стандартным советом является избегать применения собственного решения / использовать языковые решения этих проблем.

Существует ли какая-либо ранее существующая функция в PowerShell для этой цели или какой-либо рекомендуемый способ достижения этой цели; или это единственная возможность использовать сделанную на заказ функцию (например, ниже)?

function ConvertFrom-LiteralPath {
    [CmdletBinding()]
    param (
        [Parameter(Mandatory = $true, ValueFromPipeline = $true)]
        [string]$LiteralPath
    )
    process {
        (New-Object -TypeName 'PSObject' -Property @{
            LiteralPath = $LiteralPath
            Path = $LiteralPath -replace '([][[\*\?])', '`$1' # escapes ], [, *, and ?
        })
    }
}

Информация о специальных персонажах:

issue.life

Кавычки и экранирование в PowerShell

Clear-Host

Write-Host '1)'
Write-Host "String text"
Write-Host 'String text'

$var = 1057 # объявим переменную и занесем в нее числовое значение, равное 1057
''
Write-Host '2)'
Write-Host "$var" # в двойных кавычках символ $ интерпретируется как специальный
Write-Host '$var' # в одинарных кавычках символ $ интерпретируется как текст
''
Write-Host '3)'
Write-Host '"$var"' # двойные кавычки внутри одинарных интерпретируются как текст
Write-Host "'$var'" # точно также интерпретируются и одинарные кавычки внутри двойных
''
Write-Host '4)'
Write-Host 'somestring ''quotes into quotes''' # если внутри одинарных кавычек нам нужно поставить еще одинарные кавычки, интерпретируемые как текст, можно воспользоваться двумя подряд символами одинарных кавычек
Write-Host "somestring ""quotes into quotes""" # по аналогии и с двойными кавычками
''
Write-Host '5)'
Write-Host "somestring `"quotes into quotes`"" # обратная кавычка экранировала двойную. Такой способ не работает с одинарными кавычками
Write-Host "`$var = $var" # с помощью обратной кавычки мы экранировали специальный символ $
''
Write-Host '6)'
Get-Process -Name svchost `
                            | Sort-Object -Property id `
                            | Select-Object -First 3 `
                            | Format-Table -Property id,name -AutoSize -Wrap # также, с помощью обратной кавычки, можно разбивать однострочный командлет на несколько строк для удобства чтения кода. По сути, таким образом, экранируется символ перехода на новую строку

1)
String text
String text

2)
1057
$var

3)
"$var"
'1057'

4)
somestring 'quotes into quotes'
somestring "quotes into quotes"

5)
somestring "quotes into quotes"
$var = 1057

6)

  Id Name   
  -- ----   
 920 svchost
1256 svchost
1328 svchost

vam.in.ua

Как мне работать с пробелом при экранировании символа двойной кавычки в Power-Shell

PowerShell имеет скрытую логику повторного цитирования, когда аргументы передаются внешним утилитам .

То, что вы видите, это ошибка в Windows PowerShell (которая с тех пор была исправлена ​​в PowerShell Core ):

Короче говоря, "cn=\`"Jim Carter\`""передается внешнему исполняемому файлу as cn=\"Jim Beam\", который неожиданно превращается в два аргумента — обратите внимание, что аргумент не заключен в двойные кавычки в целом , даже если это необходимо.

обходные:

Как часть отличительного имени в Active Directory, значения компонентов (например, Jim Beamдля полей cn) обычно не нуждаются в двойных кавычках, даже если они содержат пробелы. Поэтому, возможно, будет работать следующее (в зависимости от поведения исполняемого файла, который вы вызываете).

someExternalTool.exe "cn=Jim Beam"

Если вам не нужно исполняемый файл , чтобы в конечном итоге увидеть строковый литерал cn=\"Jim Beam\", вы должны использовать --%, в символ остановки разбора :

someExternalTool.exe --% "cn=\\\"Jim Beam\\\""

^{Если вы хотите, чтобы исполняемый файл просто видел cn="Jim Beam", то есть с "символами. не сбежал, используйтеsomeExternalTool.exe --% "cn=\"Jim Beam\""}

Обратите внимание, что использование --%затем исключает использование переменных PowerShell как части той же команды.

В PowerShell Core , ваш исходный аргумент, "cn=\`"Jim Carter\`""приведет к тому, что целевая программа увидит буквальный аргумент cn="Jim Beam", поэтому проблема с неожиданным разделением аргументов не возникнет; однако если вам нужна целевая программа для просмотра cn=\"Jim Beam\", вам придется использовать "cn=\\\`"Jim Beam\\\`""— или, используя одинарные кавычки, 'cn=\\\"Jim Beam\\\"'

Как в стороне: необходимость явно- \ ESCEPS "символов. для того, чтобы передать их внешним программам, это само по себе должно рассматриваться как ошибка , но это давняя ошибка , которая, вероятно, не будет исправлена ​​из-за обратной совместимости: см. эту проблему GitHub .

issue.life