Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Это [p]явно[/p] указано в описании параметра ("Wildcards are accepted").

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

S>>А здесь я что, указывают регулярное выражение? Нет, конечно — я указываю путь к файлу.

ЕМ>В -Path Вы указываете шаблон пути к файлу.

Так может и стоило бы назвать -PathTemplate? Названо Path а реально имеем не Path а PathTemplate.

Не было бы проблем, если бы шаблонные символы были стандартными и запрещены в именах файлов. Но здесь нет — здесь есть символы, которые в именах файлах так же разрешены.

ЕМ>С чего вдруг? New-Item создает конкретный объект с полностью определенным именем. Как Вы представляете себе создание объекта, имя которого представлено шаблоном? А Get-Item/Get-ChildItem выбирают множество существующих объектов, имена которых подпадают под заданное условие (шаблон).

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

По уму, если они вводят сверх стандартных символов * ? еще и какие-то свои, которые могут быть частью имени файла — то назвать PathTemplate

S>>С 1 по 9 пример — получение файлов по пути — везде указан -Path. LiteralPath ни в одном примере нет
ЕМ>

Просьба ответить по существу. Откуда я должен знать что Path — это не путь а какой-то шаблон пути с символами, которые они сами решили назначить управляющими и которые могут быть частью имени файла?

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

S>вызываю эту функцию с корнем диска. Оно перебирает все папки, но не перебирает файлы внутри папки с [].

Ваш пример точно работает после замены -Path на -LiteralPath в -Get-ChildItem?

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ваш пример точно работает после замены -Path на -LiteralPath в -Get-ChildItem?

ЕМ>Если в строке, передаваемой в -Path, нет шаблонных выражений, она интерпретируется, как литеральная. Если Вы указываете "-Path c:\", то шаблонной интерпретации не происходит — формируется полный список подкаталогов корневого каталога, и никакой фильтрации по именам там нет. Если в корневом каталоге есть имена, содержащие квадратные скобки — они так же включаются в список.

ЕМ>А если Вы полученные имена затем передаете параметром в другие операции, указывая их, как шаблоны, а не буквальные строки, то операция интерпретирует их, как шаблон.

Там же рекурсивная функция — она вызывает саму себя для каждого ChildItem, если он папка.

И среди подпапок есть те, которые содержат в названии папки []

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

S>Так обычно под этим подразумеваются стандартные управляющие символы, которые не могут совпадать с именем файла или папки.

Это нужно читать, как "я это всегда подразумевал, и самонадеянно полагал, что так везде и будет". И еще раз: то, что "*" и "?" не допускаются в именах файлов — следствие исключительно того, что этим символы выбраны в качестве шаблонных для пользовательских утилит. Средства программирования этой традиции следовать не обязаны, ибо не предназначены для рядового пользователя.

А мне вот традиционных "*" и "?" никогда не хватало, поэтому в каждом новом языке/средстве я первым делом смотрю, как там интерпретируются шаблоны, допускаются ли регулярные выражения и т.п.

S>Так может и стоило бы назвать -PathTemplate?

С этим согласен. Но разработчики PowerShell, как и в свое время bash, руководствовались весьма странной логикой. Что-то сделали очень удобно, а что-то — откровенно уродливо и громоздко. Судя по всему, и там, и там сперва пытались выдержать какой-то единый стиль, но в итоге нагромоздили столько исключений, что того стиля почти не видно.

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

В средствах программирования для этого нет ни малейшей необходимости. Не путайте с утилитами для необразованного конечного пользователя.

S>здесь есть символы, которые в именах файлах так же разрешены.

А в регулярных выражениях есть символы, которые разрешены в текстах. Пора бы уже понять эту простую идею, коли Вы сподобились заняться программированием.

S>Имя с шаблоными символами создать не возможно

Невозможно создать имя с запрещенным символом. Запрещенный символ в общем случае не является шаблонным, и шаблонные символы (опять же в общем случае) не обязаны быть запрещенными в именах.

S>По уму

Вас не удивляет, что, откровенно протупив во вполне очевидном вопросе, Вы упрекаете кого-то в нехватке ума?

S>если они вводят сверх стандартных символов * ? еще и какие-то свои, которые могут быть частью имени файла — то назвать PathTemplate

Стоило так назвать не потому, что символы допустимы или недопустимы в имени, а потому, что строки в -Path и -LiteralPath имеют разный смысл и, как следствие, разную интерпретацию. Когда обрабатывается шаблон, обработчику нет дела до того, какие символы допустимы или недопустимы в имени файла — он просто применяет к ним установленные правила.

S>Просьба ответить по существу.

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

S>Откуда я должен знать что Path — это не путь а какой-то шаблон

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

В общем, не ведите себя, как школьница, которую обманом затащили в бордель.

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

S>Там же рекурсивная функция — она вызывает саму себя для каждого ChildItem, если он папка.

Я не люблю без крайней нужды разбирать чужой код, предпочитая описание.

S>И среди подпапок есть те, которые содержат в названии папки []

В описании проблемы Вы утверждали, будто Get-ChildItem "просто игнорит" такие папки. То есть, Вы еще и толком не поняли, как работает Ваш собственный код, что возвращает Get-ChildItem, что передается в функцию и т.п. Могли бы тупо вставить отладочные печати — возможно, это навело бы на правильные мысли. Вместо этого, Вы ринулись сюда размахивать флагом. А потом удивляетесь, когда Вас воспринимают, как клоуна-бездельника.

Здравствуйте, Евгений Музыченко, Вы писали:

S>>И среди подпапок есть те, которые содержат в названии папки []

ЕМ>В описании проблемы Вы утверждали, будто Get-ChildItem "просто игнорит" такие папки.

Ну вот когда спускается вниз и доходит до папки, в названии которое есть [] и пытается получить детей — то возвращает пустой список.

ЕМ>То есть, Вы еще и толком не поняли, как работает Ваш собственный код, что возвращает Get-ChildItem, что передается в функцию и т.п. Могли бы тупо вставить отладочные печати — возможно, это навело бы на правильные мысли. Вместо этого, Вы ринулись сюда размахивать флагом. А потом удивляетесь, когда Вас воспринимают, как клоуна-бездельника.

С чего не понял? Я так и сделал — поставил вывод каждой папки в консоль. Потом запустил в режиме отладки и увидел что когда Path содержит папку, в названии которой есть [] — то детей не возвращает, как будто папка пустая, а она нифига не пустая.

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

S>Ну вот когда спускается вниз и доходит до папки, в названии которое есть [] и пытается получить детей — то возвращает пустой список.

В исходном сообщении Вы описали проблему не так. Там написано: "Get-ChildItem -Path ... не работает для папок, в пути которых есть символы []. Содержание таких папок просто игнорит".

Если Вы выполните (хоть вручную) "Get-ChildItem -Path . -Recurse", то получите содержимое всех папок дерева, независимо от их имен. То есть, Вы описали проблему некорректно — дело не в тех символах, что в именах папок/файлов, а в тех, что в параметре -Path. Более корректное описание выглядело бы примерно так: "при указании в параметре -Path строки с символами [], папки с такими именами не находятся".

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В исходном сообщении Вы описали проблему не так. Там написано: "Get-ChildItem -Path ... не работает для папок, в пути которых есть символы []. Содержание таких папок просто игнорит".

Именно так.

ЕМ>Если Вы выполните (хоть вручную) "Get-ChildItem -Path . -Recurse",

Про -Recurse речи не было.

Мне не подходит -Recurse, т.к. там 2 млн. папок очень долго ждать пока оно соберет весь список. По этому обхожу рекурсивно в ручном режиме папка за папкой.

ЕМ>То есть, Вы описали проблему некорректно — дело не в тех символах, что в именах папок/файлов, а в тех, что в параметре -Path. Более корректное описание выглядело бы примерно так: "при указании в параметре -Path строки с символами [], папки с такими именами не находятся".

Я сроку не указываю а передаю результат, который вернула Get-ChildItem.

Если бы я написал так — то можно было бы подумать, что символы [] являются управляющими внутри строки (типа символа $) и я просто забыл их заэкранировать. Но нет, я не пишу строку вручную — а просто подсовываю переменную с тем значением, которое вернула сама же Get-ChildItem.

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

ЕМ>>Там написано: "Get-ChildItem -Path ... не работает для папок, в пути которых есть символы []. Содержание таких папок просто игнорит".

S>Именно так.

Нет, не так. Повторяю: проблема не в том, какие символы в именах папок, а в том, какие символы в параметре -Path.

S>Я сроку не указываю а передаю результат, который вернула Get-ChildItem.



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

S>можно было бы подумать, что символы [] являются управляющими внутри строки

Об этом не нужно как-то дополнительно думать — они действительно являются "управляющими" в том смысле, что имеют значение, отличное от буквального. И сам факт наличия параметра -LiteralPath должен сразу же наводить на мысль, что он существует неспроста.

S>(типа символа $) и я просто забыл их заэкранировать.

Это если там вообще предусмотрена возможность экранирования.

S>Я не пишу строку вручную — а просто подсовываю переменную



Попробуйте все-таки начать изучать программирование, с азов. Иногда это помогает.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Нет, не так. Повторяю: проблема не в том, какие символы в именах папок, а в том, какие символы в параметре -Path.

В параметре Path указан путь к папке. Если путь содержит в себе символы [] — то это не работает. Поведение не очевидно.

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

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

S>>Я сроку не указываю а передаю результат, который вернула Get-ChildItem.

ЕМ>

ЕМ>Ваши проблемы от того, что Вы лезете в профессиональную сферу с замашками типичного потребителя. Выходов только два: либо изучать предметную область (становиться профессионалом), либо пользоваться только средствами, ориентированными на потребителя (есть визуальные средства автоматизации, где можно мышкой накликать типовые условия и действия).

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

Люди мне благодарны, т.к. это поведение не выглядит очевидным. Зачем вы беретесь защищать глупость — не ясно.

S>>можно было бы подумать, что символы [] являются управляющими внутри строки

ЕМ>Об этом не нужно как-то дополнительно думать — они действительно являются "управляющими" в том смысле, что имеют значение, отличное от буквального. И сам факт наличия параметра -LiteralPath должен сразу же наводить на мысль, что он существует неспроста.

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

S>>(типа символа $) и я просто забыл их заэкранировать.
ЕМ>Это если там вообще предусмотрена возможность экранирования.

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

S>>Я не пишу строку вручную — а просто подсовываю переменную
ЕМ>
ЕМ>Попробуйте все-таки начать изучать программирование, с азов. Иногда это помогает.

Давай конкретно. Написать строку вручную — можно не учесть экранирования символов. И я подчеркнул что строку не писал вручную — даю значение переменное, которую сформировал сам же Get-ChildItem.

Здравствуйте, 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.

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

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

vsb>>Думаю, что и power shell на макоси поставить можно в пару условных кликов. Да и что угодно где угодно.

N>И как?

brew install powershell/tap/powershell

Если человек использует скрипты, скорей всего homebrew у него есть.

Ну или скачать pkg и протыкать в инсталляторе.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Не "игнорит", а интерпретирует символы, как элемент шаблона (wildcard), наравне с традиционными "*" и "?".

Почему видно что это шаблон, а не путь? Написано путь. На счет традиционных — нет проблем, они по общим договоренностям не могут быть именем файла. А почему какие-то кастомные ввели, причем в доке по приведенной мной ссылке нет ни одного примера, где бы список файлов получали через -LiteralPath, нет ни слова о том что это шаблон с какими-то своими кастомными символами.

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

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

Н>Python изучаю. Жаль что не начал делать этого раньше. Очень клевая штука
Н>Вот он как раз для таких задачек.

Н>Так что совет — не использовать всякую фигню

Питон? длай варианта команды dir (ls)?
Ну вы, блин, даёте.

ЗЫ: PS — для этого тоже выглядит монструозно.

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

S>Почему видно что это шаблон, а не путь?

Потому, что об этом говорит документация.

S>Написано путь.

Если Вы про буквальную интерпретацию имени параметра (-Path), то это действительно некий путь, определяющий местонахождение требуемой сущности. От того, что путь может содержать метасимволы, он не перестает быть путем.

S>А почему какие-то кастомные ввели, причем в доке по приведенной мной ссылке нет ни одного примера, где бы список файлов получали через -LiteralPath

Вы определенно занимаетесь не своим делом. Ваши рассуждения об этом не просто глупы — они убоги, и вызывают даже не столько недовольство и злость, сколько брезгливость.

S>нет ни слова о том что это шаблон с какими-то своими кастомными символами.

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

Здравствуйте, Евгений Музыченко, Вы писали:

S>>Почему видно что это шаблон, а не путь?
ЕМ>Потому, что об этом говорит документация.

К именованиям нужно подходить очень тщательно, дабы не вводить в заблуждение.

А то назовете палец — а это жопа. А почему жопа, ведь а написано палец? А ты в документацию посмотри.

Глупостей не говорите.

ЕМ>Вы определенно занимаетесь не своим делом.

Если вы так и в своих проектах именуете сущности — то я бы вас на работу брать никому не рекомендовал. Вы хотя бы посмотрели бы на стартовое сообщение — люди мне благодарны.