Здравствуйте, Shmj, Вы писали:

S>В параметре Path указан путь к папке.

Нет. В параметре указано строковое выражение, трактуемое, как шаблон пути к папке.

S>Поведение не очевидно.

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

S>То что это не путь а шаблон с какими-то своими правилами — не очевидно.

Исключительно для неучей и упрямцев.

S>Причем для других команд этот же Path уже трактует символы не как шаблонные.

Не для "других", а для тех, где путь указывает на конкретный, единственный объект, а не множество объектов, объединенных какими-то признаками. Единственный объект является частным случаем множества, но не наоборот.

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

S>Вы на личности не переходите, а отвечайте по существу.

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

S>Люди мне благодарны

Которые? Где?

S>т.к. это поведение не выглядит очевидным.

Так я согласился с Вами в том, что имя параметра выбрано не совсем удачно. Чтобы понять, почему так получилось, нужно изучать историю разработки PowerShell. Поскольку она сильно смахивает на bash, к ее разработке явно приложили руки соответствующие фанаты. А поскольку в основе работы с данными в языке bash лежит текстовая подстановка, и там любой путь является шаблоном, то и PowerShell исходно могли проектировать на том же принципе, но в какой-то момент одумались.

S>Зачем вы беретесь защищать глупость

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

ЕМ>>-LiteralPath

S>В примерах работы с файловой системой он не задействован.

В любой документации примеры являются лишь приятным дополнением, и никогда не являются обязательной частью. Если Вам удобнее изучать средства программирования именно на примерах — ищите литературу вида "XXX в примерах и картинках". Только не обижайтесь, если там будет приписка "для чайников", "для нубов" и т.п.

S>Возможно что он нужен для работы с другими ресурсами, не с файлами.

Что значит "возможно"? Вы ж еще в первом сообщении вроде как пришли к выводу, что это именно то, что и требуется в задачах вроде Вашей.

S>Управляющие символы внутри строки (обычно \) всегда во всех языках можно заэкранировать

Не "всегда" и не "во всех языках" — это определяется синтаксисом и семантикой языка. В ряде языков, за ненадобностью, вообще нет понятия "управляющего символа" в строке.

S>иначе глупость получится, что невозможно записать строку с некими символами.

Нет, получится просто "невозможность записать строку с некими символами". Глупость — с высоты своего невежества считать, что любой язык обязан давать возможность записать любую строку.

S>я подчеркнул что строку не писал вручную — даю значение переменное, которую сформировал сам же Get-ChildItem.

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