Это не работает для папок, в пути которых есть символы []. Содержание таких папок просто игнорит
D:\folder_[10]\subfolder1
И нужно использовать не -Path а -LiteralPath.
Знали ли вы об этом? Вот пока не столкнешься — будешь верить что код работает и там же все просто. Ан, нет, что еще раз доказывает тезис — наш мир только в теории кажется простым, пока не попытаешься что-либо сделать.
Как нужно бороться с подобными ошибками?
З.Ы.
Причина в том, что на самом деле это не -Path а шаблон. И символы [] — воспринимает как часть шаблона для поиска — типа [bc]ook matches book and cook. Так же можно использовать и традиционные ? и *, но еще решили добавить и свои кастомные [], которые отдельно могут быть именем папки.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Нomunculus, Вы писали:
Н>>Python изучаю. Жаль что не начал делать этого раньше. Очень клевая штука
S>Так PowerShell — работает по умолчанию без установки чего-либо дополнительного.
Ты ж на маке. Там как раз питон
Re[4]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Нomunculus, Вы писали:
Н>Ты ж на маке. Там как раз питон
Я везде. Будущее за кросс-платформой, т.е всеядностью. Когда вы кушаете только одну еду и брезгуете другой — то будете как Панды — выживите лишь в искусственных условиях по милости господ, если будете достаточно мягкими и пушистыми.
=сначала спроси у GPT=
Re[5]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Shmj, Вы писали:
S>Это не работает для папок, в пути которых есть символы []. Содержание таких папок просто игнорит
Не "игнорит", а интерпретирует символы, как элемент шаблона (wildcard), наравне с традиционными "*" и "?".
S>И нужно использовать не -Path а -LiteralPath.
Как и во всех остальных языках/утилитах, которые предполагают в строках наличие метасимволов, или экранировать их предусмотренным образом.
S>Знали ли вы об этом?
Я не знал (редко использую PowerShell), но из документации по Вашей ссылке это видно однозначно. Уже само наличие -LiteralPath в дополнение к -Path должно было навести на мысль, если бы Вы начали с документации.
S>Как нужно бороться с подобными ошибками?
Не делать вида, будто, взяв нагугленный где-то готовый пример, и наскоро переделав под себя, Вы действительно "смотрели доку" до того, а не после того, как нарвались.
Re[2]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Не "игнорит", а интерпретирует символы, как элемент шаблона (wildcard), наравне с традиционными "*" и "?".
Но ведь * и ? — запрещены в названиях папок и файлов — здесь вопросов нет. А вот [] — разрешены, по этому просто так использовать их как спец. символы — было не разумно.
S>>И нужно использовать не -Path а -LiteralPath.
ЕМ>Как и во всех остальных языках/утилитах, которые предполагают в строках наличие метасимволов, или экранировать их предусмотренным образом.
Так это же не к строке относится — в строках они ничего не значат. Это именно к -Path. Причем для New-Item, к примеру, — нет особого Literal-Path — только -Path.
S>>Знали ли вы об этом?
ЕМ>Я не знал (редко использую PowerShell), но из документации по Вашей ссылке это видно однозначно. Уже само наличие -LiteralPath в дополнение к -Path должно было навести на мысль, если бы Вы начали с документации.
В первом примере нет -LiteralPath.
S>>Как нужно бороться с подобными ошибками? ЕМ>Не делать вида, будто, взяв нагугленный где-то готовый пример, и наскоро переделав под себя, Вы действительно "смотрели доку" до того, а не после того, как нарвались.
Если в доке будут такие подлянки — то ты ее будешь учить годами и все-равно знать не будешь. Пока выучишь — язык станет не актуальным.
=сначала спроси у GPT=
Re[3]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Shmj, Вы писали:
S>Но ведь * и ? — запрещены в названиях папок и файлов — здесь вопросов нет. А вот [] — разрешены
Это вообще никак не связано. Про регулярные выражения слышали? В текстах, к которым они применяются, нужно запретить символы ".", "*", "+", скобки и прочее?
S>просто так использовать их как спец. символы — было не разумно.
Их используют не "просто так", а в средстве автоматизации, реализующем язык программирования. Неразумно — пользоваться подобными средствами так, как ими пользуется неграмотный юзер.
S>Так это же не к строке относится
Параметром -Path и -LiteralPath является строковый тип данных.
S>Причем для New-Item, к примеру, — нет особого Literal-Path — только -Path.
И почему же это, интересно? Попробую догадаться... А! Наверное, потому, что "шаблонная" интерпретация символов в New-Item не имеет смысла, да? Угадал?
S>В первом примере нет -LiteralPath.
Почему он должен быть непременно в первом примере, а не втором, пятом или двенадцатом?
S>Если в доке будут такие подлянки
В упомянутой доке нет никаких "подлянок" — все описано, как есть. То, что доку писали для тех, кто будет ее читать, а не проглядывать наскоро — проблема читателя, а не доки. Вы просто откровенно лопухнулись, но отчаянно не хотите этого признавать.
S>ты ее будешь учить годами
Учат доки только те, кто не понимает сути, и применяет средства тупо, по шаблону и аналогии. Те, кто понимает принцип устройства и работы, читают один раз полностью для общего понимания, затем читают только нужные фрагменты для освежения памяти.
Re[7]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, vsb, Вы писали:
vsb>На винде нет питона.
Вот это спорный момент. Нет в инсталяторе? Да, нет. Но поставить его — пара кликов, можешь убедиться в этом на apps.microsoft.com. Так что я бы не делал из этого проблемы.
Re[8]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Nuzhny, Вы писали:
vsb>>На винде нет питона.
N>Вот это спорный момент. Нет в инсталяторе? Да, нет. Но поставить его — пара кликов, можешь убедиться в этом на apps.microsoft.com. Так что я бы не делал из этого проблемы.
Думаю, что и power shell на макоси поставить можно в пару условных кликов. Да и что угодно где угодно.
Когда питон появится в только что установленной винде, тогда будет такой вариант. Вот в макоси он стоит, хотя там свои нюансы и его вообще не рекомендуется использовать для своих скриптов, но технически он есть и работает. В линуксах — тут, конечно, где как, но в большинстве дистрибутивов не в минимальных установках он таки тоже есть. А в винде — нет. Там только bat-файлы из всем известного. В последнее время стали powershell ставить. Ну JS и VBS из экзотики вроде поддерживаются, хотя точно не уверен.
IMHO, запутанное экранирование строк это общая проблема всех языков, предназначенных для shell scripting (powershell, posix shell).
Решение — по возможности не использовать shell scripting, оставив его сис.админам
По-моему под MS Windows ещё можно писать скрипты на VB script.
Re[9]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, m2user, Вы писали:
M>IMHO, запутанное экранирование строк это общая проблема всех языков, предназначенных для shell scripting (powershell, posix shell).
Это не экранирование строк. Я считываю имя файла в переменную, не пишу руками. И эту же переменную использую для поиска дочерних файлов:
function Process-Folder {
param(
[string]$folderPath
)
$items = Get-ChildItem -Path $folderPath -Force | Sort-Object Name
foreach ($item in $items) {
if ($item.PSIsContainer) {
Process-Folder -folderPath $item.FullName
} elseif ($item.Extension -eq ".zip") {
Expand-ZipFile -zipFile $item.FullName
}
}
}
Т.е. вызываю эту функцию с корнем диска. Оно перебирает все папки, но не перебирает файлы внутри папки с [].
=сначала спроси у GPT=
Re[4]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это вообще никак не связано. Про регулярные выражения слышали? В текстах, к которым они применяются, нужно запретить символы ".", "*", "+", скобки и прочее?
А здесь я что, указывают регулярное выражение? Нет, конечно — я указываю путь к файлу.
Понятно что символы * и ? не могут быть в пути файла и используются шаблон. Но вот те символы которые могут быть частью имени файла или папки — с чего вдруг трактуются как шаблон?
S>>просто так использовать их как спец. символы — было не разумно. ЕМ>Их используют не "просто так", а в средстве автоматизации, реализующем язык программирования. Неразумно — пользоваться подобными средствами так, как ими пользуется неграмотный юзер.
Это путь к файлу а не регулярное выражение.
S>>Так это же не к строке относится ЕМ>Параметром -Path и -LiteralPath является строковый тип данных.
И что? Вы запутали человека выше — он подумал что проблема в экранировании символов, типа я написал символы \t и ожидал что они будет будет распарсены не как табуляция, а как буквальный слэш и буква t. Но здесь дело не в этом.
S>>Причем для New-Item, к примеру, — нет особого Literal-Path — только -Path. ЕМ>И почему же это, интересно? Попробую догадаться... А! Наверное, потому, что "шаблонная" интерпретация символов в New-Item не имеет смысла, да? Угадал?
Т.е. вы считаете это нормальным? По идее нужно все-равно трактовать как шаблонные символы и выдавать ошибку.
S>>В первом примере нет -LiteralPath.
ЕМ>Почему он должен быть непременно в первом примере, а не втором, пятом или двенадцатом?
С 1 по 9 пример — получение файлов по пути — везде указан -Path. LiteralPath ни в одном примере нет
S>>Если в доке будут такие подлянки
ЕМ>В упомянутой доке нет никаких "подлянок" — все описано, как есть. То, что доку писали для тех, кто будет ее читать, а не проглядывать наскоро — проблема читателя, а не доки. Вы просто откровенно лопухнулись, но отчаянно не хотите этого признавать.
Кто еще так думает?
=сначала спроси у GPT=
Re[5]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Shmj, Вы писали:
S>А здесь я что, указывают регулярное выражение? Нет, конечно — я указываю путь к файлу.
В -Path Вы указываете шаблон пути к файлу. Это [p]явно[/p] указано в описании параметра ("Wildcards are accepted"). Но Вы решили, что описание параметров — не для Вас, и дочитали только до примеров. Само по себе это не страшно — я тоже периодически так нарываюсь. А вот то, что подняли хай насчет "подлянки" вместо того, чтоб самого себя стукнуть по голове — это уровень тупого юзера, а не программиста.
S>те символы которые могут быть частью имени файла или папки — с чего вдруг трактуются как шаблон?
С того, что шаблон в PowerShell может содержать символы, допустимые в имени файла. Точно так же, регулярное выражение, применяемое к произвольному тексту, не накладывает никаких ограничений на символьный состав текста. Если Вас это удивляет, Вам необходимо углубить образование.
S>Это путь к файлу а не регулярное выражение.
Это шаблон пути к файлу. То есть, это текстовое выражение, описывающие множество подходящих под него путей.
S>Вы запутали человека выше — он подумал что проблема в экранировании символов
Я плохо знаком с синтаксисом PowerShell — возможно, там есть и возможность экранирования. Но экранирование не решает всех возможных проблем, поэтому и существует -LiteralPath.
ЕМ>>Наверное, потому, что "шаблонная" интерпретация символов в New-Item не имеет смысла, да?
S>Т.е. вы считаете это нормальным?
Абсолютно. Если Вы считаете это ненормальным, то Вы определенно занимаетесь не своим делом.
S>По идее нужно все-равно трактовать как шаблонные символы и выдавать ошибку.
С чего вдруг? New-Item создает конкретный объект с полностью определенным именем. Как Вы представляете себе создание объекта, имя которого представлено шаблоном? А Get-Item/Get-ChildItem выбирают множество существующих объектов, имена которых подпадают под заданное условие (шаблон).
S>С 1 по 9 пример — получение файлов по пути — везде указан -Path. LiteralPath ни в одном примере нет
Re[9]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Shmj, Вы писали:
S>Я считываю имя файла в переменную, не пишу руками. И эту же переменную использую для поиска дочерних файлов
Если переменная содержит точное имя файла, а не выражение, описывающее возможные имена, то Вы должны использовать соответствующие средства, а не первое подходящее.
Во многих ЯП функции поиска по тексту принимают в качестве образца регулярное выражение. По умолчанию оно начинается со слэша, поэтому попытка найти буквальную (literal) последовательность "/abc/" найдет вовсе не ее. Используя программные средства, программист обязан знать особенности их работы, и не возмущаться, если они работают, как описано, а не как он интуитивно предполагал.
Re[6]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это [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:\", то шаблонной интерпретации не происходит — формируется полный список подкаталогов корневого каталога, и никакой фильтрации по именам там нет. Если в корневом каталоге есть имена, содержащие квадратные скобки — они так же включаются в список.
А если Вы полученные имена затем передаете параметром в другие операции, указывая их, как шаблоны, а не буквальные строки, то операция интерпретирует их, как шаблон.
Re[4]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ваш пример точно работает после замены -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 — это не путь а какой-то шаблон
Из документации, на которую сами же и дали ссылку в первом сообщении. Она написана для того, чтобы ее читали, а не просматривали по диагонали. Единственное, что в этой документации не совсем правильно — примеры почему-то идут до подробного описания параметров. Но эти описания таки есть, они не спрятаны под спойлеры, и даже не вынесены на отдельные страницы. Если Вам раньше приходилось читать документацию по средствам программирования, то Вы не могли не знать, что любые синтаксические элементы, упомянутые в общем описании, непременно подробно описаны где-то далее. Иначе не бывает.
В общем, не ведите себя, как школьница, которую обманом затащили в бордель.
Re[5]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Shmj, Вы писали:
S>Там же рекурсивная функция — она вызывает саму себя для каждого ChildItem, если он папка.
Я не люблю без крайней нужды разбирать чужой код, предпочитая описание.
S>И среди подпапок есть те, которые содержат в названии папки []
В описании проблемы Вы утверждали, будто Get-ChildItem "просто игнорит" такие папки. То есть, Вы еще и толком не поняли, как работает Ваш собственный код, что возвращает Get-ChildItem, что передается в функцию и т.п. Могли бы тупо вставить отладочные печати — возможно, это навело бы на правильные мысли. Вместо этого, Вы ринулись сюда размахивать флагом. А потом удивляетесь, когда Вас воспринимают, как клоуна-бездельника.
Re[6]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Евгений Музыченко, Вы писали:
S>>И среди подпапок есть те, которые содержат в названии папки []
ЕМ>В описании проблемы Вы утверждали, будто Get-ChildItem "просто игнорит" такие папки.
Ну вот когда спускается вниз и доходит до папки, в названии которое есть [] и пытается получить детей — то возвращает пустой список.
ЕМ>То есть, Вы еще и толком не поняли, как работает Ваш собственный код, что возвращает Get-ChildItem, что передается в функцию и т.п. Могли бы тупо вставить отладочные печати — возможно, это навело бы на правильные мысли. Вместо этого, Вы ринулись сюда размахивать флагом. А потом удивляетесь, когда Вас воспринимают, как клоуна-бездельника.
С чего не понял? Я так и сделал — поставил вывод каждой папки в консоль. Потом запустил в режиме отладки и увидел что когда Path содержит папку, в названии которой есть [] — то детей не возвращает, как будто папка пустая, а она нифига не пустая.
=сначала спроси у GPT=
Re[7]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Shmj, Вы писали:
S>Ну вот когда спускается вниз и доходит до папки, в названии которое есть [] и пытается получить детей — то возвращает пустой список.
В исходном сообщении Вы описали проблему не так. Там написано: "Get-ChildItem -Path ... не работает для папок, в пути которых есть символы []. Содержание таких папок просто игнорит".
Если Вы выполните (хоть вручную) "Get-ChildItem -Path . -Recurse", то получите содержимое всех папок дерева, независимо от их имен. То есть, Вы описали проблему некорректно — дело не в тех символах, что в именах папок/файлов, а в тех, что в параметре -Path. Более корректное описание выглядело бы примерно так: "при указании в параметре -Path строки с символами [], папки с такими именами не находятся".
Re[8]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В исходном сообщении Вы описали проблему не так. Там написано: "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>Я не пишу строку вручную — а просто подсовываю переменную
Попробуйте все-таки начать изучать программирование, с азов. Иногда это помогает.
Re[10]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Нет, не так. Повторяю: проблема не в том, какие символы в именах папок, а в том, какие символы в параметре -Path.
В параметре Path указан путь к папке. Если путь содержит в себе символы [] — то это не работает. Поведение не очевидно.
То что это не путь а шаблон с какими-то своими правилами — не очевидно.
Причем для других команд этот же Path уже трактует символы не как шаблонные.
S>>Я сроку не указываю а передаю результат, который вернула Get-ChildItem.
ЕМ>
ЕМ>Ваши проблемы от того, что Вы лезете в профессиональную сферу с замашками типичного потребителя. Выходов только два: либо изучать предметную область (становиться профессионалом), либо пользоваться только средствами, ориентированными на потребителя (есть визуальные средства автоматизации, где можно мышкой накликать типовые условия и действия).
Вы на личности не переходите, а отвечайте по существу.
Люди мне благодарны, т.к. это поведение не выглядит очевидным. Зачем вы беретесь защищать глупость — не ясно.
S>>можно было бы подумать, что символы [] являются управляющими внутри строки
ЕМ>Об этом не нужно как-то дополнительно думать — они действительно являются "управляющими" в том смысле, что имеют значение, отличное от буквального. И сам факт наличия параметра -LiteralPath должен сразу же наводить на мысль, что он существует неспроста.
В примерах работы с файловой системой он не задействован. Возможно что он нужен для работы с другими ресурсами, не с файлами.
S>>(типа символа $) и я просто забыл их заэкранировать. ЕМ>Это если там вообще предусмотрена возможность экранирования.
Управляющие символы внутри строки (обычно \) всегда во всех языках можно заэкранировать — иначе глупость получится, что невозможно записать строку с некими символами. Но здесь другой случай.
S>>Я не пишу строку вручную — а просто подсовываю переменную ЕМ> ЕМ>Попробуйте все-таки начать изучать программирование, с азов. Иногда это помогает.
Давай конкретно. Написать строку вручную — можно не учесть экранирования символов. И я подчеркнул что строку не писал вручную — даю значение переменное, которую сформировал сам же Get-ChildItem.
=сначала спроси у GPT=
Re[11]: Подлянка с -Path/-LiteralPath в PowerShell - что дела
Здравствуйте, 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.
Вы где-то в документации видели утверждения о том, что эти случаи должны обрабатываться по-разному? Или утверждения, что строка, возвращенная некой операцией, должна трактоваться как-то иначе, чем строка, указанная литералом, сформированная при вычислении выражения и т.п.?
Re[10]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Не "игнорит", а интерпретирует символы, как элемент шаблона (wildcard), наравне с традиционными "*" и "?".
Почему видно что это шаблон, а не путь? Написано путь. На счет традиционных — нет проблем, они по общим договоренностям не могут быть именем файла. А почему какие-то кастомные ввели, причем в доке по приведенной мной ссылке нет ни одного примера, где бы список файлов получали через -LiteralPath, нет ни слова о том что это шаблон с какими-то своими кастомными символами.
=сначала спроси у GPT=
Re[2]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Нomunculus, Вы писали:
Н>Здравствуйте, Shmj, Вы писали:
Н>Python изучаю. Жаль что не начал делать этого раньше. Очень клевая штука Н>Вот он как раз для таких задачек.
Н>Так что совет — не использовать всякую фигню
Питон? длай варианта команды dir (ls)?
Ну вы, блин, даёте.
ЗЫ: PS — для этого тоже выглядит монструозно.
Спасибо за внимание
Re[3]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Shmj, Вы писали:
S>Почему видно что это шаблон, а не путь?
Потому, что об этом говорит документация.
S>Написано путь.
Если Вы про буквальную интерпретацию имени параметра (-Path), то это действительно некий путь, определяющий местонахождение требуемой сущности. От того, что путь может содержать метасимволы, он не перестает быть путем.
S>А почему какие-то кастомные ввели, причем в доке по приведенной мной ссылке нет ни одного примера, где бы список файлов получали через -LiteralPath
Вы определенно занимаетесь не своим делом. Ваши рассуждения об этом не просто глупы — они убоги, и вызывают даже не столько недовольство и злость, сколько брезгливость.
S>нет ни слова о том что это шаблон с какими-то своими кастомными символами.
Я Вам уже приводил цитату с нужными словами со страницы по Вашей собственной ссылке. Но, если то, что Вы ошибочно принимаете за гордость, не позволяет Вам признать свою ошибку — продолжайте исходить на дерьмо и дальше, а мне надоело.
Re[4]: Подлянка с -Path/-LiteralPath в PowerShell - что делать?
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Почему видно что это шаблон, а не путь? ЕМ>Потому, что об этом говорит документация.
К именованиям нужно подходить очень тщательно, дабы не вводить в заблуждение.
А то назовете палец — а это жопа. А почему жопа, ведь а написано палец? А ты в документацию посмотри.
Глупостей не говорите.
ЕМ>Вы определенно занимаетесь не своим делом.
Если вы так и в своих проектах именуете сущности — то я бы вас на работу брать никому не рекомендовал. Вы хотя бы посмотрели бы на стартовое сообщение — люди мне благодарны.
