![]() |
Удалить папку без подтверждения
Напишите, пожалуйста аналог
Код:
cmd /c rd /s /q Код:
PS C:\Windows\system32> Remove-Item -Path "$env:Temp\Folder" -Force -Confirm -Recurse -ErrorAction SilentlyContinue Цитата:
|
Цитата:
|
Порой pwsh сходит с ума из-за различных атрибутов, например, ReadOnly. Поэтому перед тем, как грохнуть папку, лучше заведомо сбросить атрибуты файлов папки до Normal. Например:
Код:
(Get-ChildItem foo -Recurse).ForEach{$_.Attribute = 'Normal'} && Remove-Item foo -Recurse -Force |
Цитата:
|
Цитата:
|
greg zakharov, спасибо, ясно.
|
Код:
-confirm:$false |
Fors1k, так то оно так, только как видите, не работает.
greg zakharov, если я правильно понял, для игнорирования атрибутов предназначен ключик -Force Спасибо, метод от DJ Mogarych сработал. Только вот, как я должен был это понять по докам? Код:
get-help Remove-Item -full Цитата:
Цитата:
И подскажите мне, пожалуйста, чем заменить магические точки ../microsoft.powershell.core чтобы попасть на сайт, указанный в доках? (боже, как же любит Майкрософт усложнять) Цитата:
Неужели не хватило места в их гигабайтовых обновлениях винды. |
Цитата:
"-Confirm" = запросить подтверждение перед выполнением. Вы написали -Confirm, он вас спросил, все как и должно быть. Цитата:
Вот нужный вам код: Код:
Remove-Item "$env:Temp\Folder" -Recurse -Force |
Цитата:
Что касается параметра -confirm: У powershell, есть много нюансов, которые не описываются в help-ах конкретных командлетов, но они являются общими для поведения многих из них. И это, как раз, тот случай. Поведение выдачи запроса на подтверждение определяется ещё и значением автопеременной $ConfirmPreference, помимо, собственно, значения по умолчанию параметра -confirm Цитата:
Цитата:
Код:
function test{ Цитата:
Цитата:
Предустановленный powershell v5.1, содержит маны и сам он уже практически не изменяется, а версии поновее, подвержены изменениям и часто значительным, поэтому и маны необходимо периодически обновлять отдельно, видимо исходили из этого... но согласен, что с документацией у микрософта были, есть и скорее всего, будут проблемы... :) |
Fors1k, согласен, каюсь, балда, без "-Confirm" отрабатывает без доп. запросов.
YuS_2, спасибо за пояснения. |
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
Вышеприведенная автопеременная, как раз, оператором не является ведь, но она регулирует приоритет выдачи запроса на подтверждение действий, а также атрибут ConfirmImpact командлетов и функций. Цитата:
А то, что изменения документации не поспевают за изменениям в самом powershell, так это вечная болячка микрософта, наверное. |
YuS_2, ещё раз. Переменные не имеют приоритета, они имеют контекст; автоматические переменные могут управлять контекстом. Чуете разницу? Это не "жестковатые" рамки, а действительность. Сами посудите: если бы переменные имели приоритет, следовательно возникла "гонка" операторов и переменных, и тогда бы вместо осмысленного итога цепочки выражений можно было бы наблюдать фигу.
И, также, что касательно документации. Документация нужна тем, кто pwsh использует не повседневно и не столь продолжительное время. |
Цитата:
Цитата:
Вопрос был в том, что приоритет присутствует не только в операторах, ибо в данном случае никакой внешний оператор (понятно, что внутри модуля он просто обязан быть, но фактически, мы его не видим) не участвует в управлении и следовательно выразиться: "приоритетом обладают, в основном, операторы", было бы точнее... Цитата:
Цитата:
|
Цитата:
Код:
контекст -ne приоритет |
Цитата:
Цитата:
Вижу, что требуется уточнение: я не говорил этого, а именно того, что переменные имеют приоритет. Всего лишь, говорил о том, что приоритет может быть не только у операторов. А это две большие разницы. Код:
"регулировать приоритет" -ne "наличие приоритета у регулятора" А если ещё уточнить, то и у запуска некоторых командлетов, тоже есть приоритеты, без оператора, всего лишь указанием аргумента, например, Start-BitsTransfer... у политики выполнения скриптов есть приоритетность, которая регулируется без помощи операторов... и т.д. ЗЫ И хватит уже выкать мне. Насколько я помню, мы давно переходили на ты, хоть и не здесь это было... :) |
Время: 22:14. |
Время: 22:14.
© OSzone.net 2001-