Comments 8
Меня мучает вопрос, который мне мешает учить PowerShell:
Много ли причин писать
вместо
И зачем так извращаться? Эта избыточность синтаксиса меня просто убивает.
Много ли причин писать
new-item -Name WindowsPowerShell -ItemType directory
вместо
mkdir WindowsPowerShell
И зачем так извращаться? Эта избыточность синтаксиса меня просто убивает.
Совсем необязательно использовать подробный синтаксис, mkdir прекрасно работает в Powershell в виде обертки над New-item. Более того, есть алиас md.
Так можно же посмотреть список и обязательность аргументов командлета через help имя_командлета -full и указывать только обязательные аргументы.
Потом, можно заранее посмотреть список алиасов через get-command -CommandType alias.
Потом, можно заранее посмотреть список алиасов через get-command -CommandType alias.
Все достаточно сильно зависит от обстоятельств.
Если вы единственный пользователь ваших скриптов, то вам, возможно, и нет смысла использовать подробный синтаксис. Если вы до этого все задачи решали с помощью обычных cmd-файлов, powershell позволит вам использовать (до определенной степени) привычные вам имена команд и их формы.
Подробный синтаксис полезен и удобен, когда вы пишите скрипты, которые придется поддерживать и изменять со временем (особенно тогда, когда это придется делать не вам). Когда над скриптами работают разные люди, с разным уровнем знания команд, пришедших из cmd, и псевдонимов кмдлетов. Подробный синтаксис дольше писать, но как правило, его удобнее читать.
Сравните строки:
Если ваш коллега нетвердо помнит значение всех использованных псевдонимов в первой строке, то ему придется потратить время на воспоминания. Вторая строка читается дольше, но понимается быстрее.
Плюс производитель не гарантирует, что все псевдонимы будут поддерживаться во всех средах, поэтому полные названия кмдлетов надежнее.
Аналогично с указыванием названий параметров. Вот две строки
Если читающему не знаком подробно кмдлет Set-AzureAclConfig, то ему будет непонятно что означают первые 3 параметра в первой строке. А при чтении второй строки такого непонимания нет.
Mkdir WindowsPowerShell – наверное достаточно понятно и можно было бы написать и так, но у меня уже привычка почти все писать полными именами кмдлетов (почти, потому что cd я все таки использую). К тому же автозавершение и другие фичи в средах разработки очень упрощают прописывание подробного синтаксиса.
Если вы единственный пользователь ваших скриптов, то вам, возможно, и нет смысла использовать подробный синтаксис. Если вы до этого все задачи решали с помощью обычных cmd-файлов, powershell позволит вам использовать (до определенной степени) привычные вам имена команд и их формы.
Подробный синтаксис полезен и удобен, когда вы пишите скрипты, которые придется поддерживать и изменять со временем (особенно тогда, когда это придется делать не вам). Когда над скриптами работают разные люди, с разным уровнем знания команд, пришедших из cmd, и псевдонимов кмдлетов. Подробный синтаксис дольше писать, но как правило, его удобнее читать.
Сравните строки:
Ls | ? {$_.psiscontainer} | % {“{0}`t{1}” –f $_.name, $_.lastaccesstime}
Get-ChildItem | Where-Object {$_. Psiscontainer} | ForEach-Object {“{0}`t{1}” –f $_.name, $_.lastaccesstime}
Если ваш коллега нетвердо помнит значение всех использованных псевдонимов в первой строке, то ему придется потратить время на воспоминания. Вторая строка читается дольше, но понимается быстрее.
Плюс производитель не гарантирует, что все псевдонимы будут поддерживаться во всех средах, поэтому полные названия кмдлетов надежнее.
Аналогично с указыванием названий параметров. Вот две строки
Set-AzureAclConfig “192.168.0.0/8” 100 “SiteConfig” –AddRule –ACL $AclObject –Action Permit
Set-AzureAclConfig -RemoteSubnet “192.168.0.0/8” -Order 100 –Description “SiteConfig” –AddRule –ACL $AclObject –Action Permit
Если читающему не знаком подробно кмдлет Set-AzureAclConfig, то ему будет непонятно что означают первые 3 параметра в первой строке. А при чтении второй строки такого непонимания нет.
Mkdir WindowsPowerShell – наверное достаточно понятно и можно было бы написать и так, но у меня уже привычка почти все писать полными именами кмдлетов (почти, потому что cd я все таки использую). К тому же автозавершение и другие фичи в средах разработки очень упрощают прописывание подробного синтаксиса.
Думаю, стоить упомянуть возможность запуска тестов Pester напрямую из Visual Studio с помощью PowerShell Tools for Visual Studio.
Простите, почему не указано что это перевод?
www.powershellmagazine.com/2014/03/12/get-started-with-pester-powershell-unit-testing-framework
www.powershellmagazine.com/2014/03/12/get-started-with-pester-powershell-unit-testing-framework
Sign up to leave a comment.
Использование Pester для тестирования при разработке PowerShell скриптов