Learn windows powershell in a month of lunches на русском

Learn PowerShell in a Month of Lunches: Covers Windows, Linux, and macOS, 4th Edition

Автор: TRex от 23-03-2022, 09:57, Коментариев: 0

Категория: КНИГИ » ОС И БД

Summary

Learn Windows PowerShell in a Month of Lunches, Third Edition is an innovative tutorial designed for busy IT professionals. This updated edition covers PowerShell features that run on Windows 7, Windows Server 2008 R2 and later, PowerShell v3 and later, and includes v5 features like PowerShellGet.

Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications.

About the Technology

PowerShell is both a scripting language and an administrative shell that lets you control and automate nearly every aspect of Windows. It accepts and executes commands interactively and you can write scripts to manage most Windows servers like Exchange, IIS, and SharePoint, as well as online services like Azure and Office 365.

About the Book

Learn Windows PowerShell in a Month of Lunches, Third Edition is an innovative tutorial designed for busy IT professionals. Just set aside one hour a day lunchtime would be perfect for a month, and you’ll be automating Windows tasks faster than you ever thought possible. This updated edition covers PowerShell features that run on Windows 7, Windows Server 2008 R2 and later, PowerShell v3 and later, and includes v5 features like PowerShellGet.

What’s Inside

• Learn PowerShell from the beginning, no experience required!
• Covers PowerShell v3 and up, Windows 7, and Windows Server 2008 R2 and later
• Each lesson takes you an hour or less

About the Reader

Experience with Windows administration is helpful. No programming or scripting experience needed.

About the Author

Veteran PowerShell MVPs Don Jones and Jeffery Hicks bring years as successful trainers to this concise, easy to follow book.

Table of Contents

1. Before you begin
2. Meet PowerShell
3. Using the help system
4. Running commands
5. Working with providers
6. The pipeline: connecting commands
7. Adding commands
8. Objects: data by another name
9. The pipeline, deeper
10. Formatting and why it’s done on the right
11. Filtering and comparisons
12. A practical interlude
13. Remote control: one to one, and one to many
14. Using Windows Management Instrumentation and CIM
15. Multitasking with background jobs
16. Working with many objects, one at a time
17. Security alert!
18. Variables: a place to store your stuff
19. Input and output
20. Sessions: remote control with less work
21. You call this scripting?
22. Improving your parameterized script
23. Advanced remoting configuration
24. Using regular expressions to parse text files
25. Additional random tips, tricks, and techniques
26. Using someone else’s script
27. Never the end
28. PowerShell cheat sheet

Learn Windows PowerShell in a Month of Lunches, Third Edition you own this product

placing your order.

Don’t refresh or navigate away from the page.

Superb. full of real-world examples, this book is an IT specialist’s best friend.

Olivier Deveault, Voxco Group

Learn Windows PowerShell in a Month of Lunches, Third Edition is an innovative tutorial designed for busy IT professionals. This updated edition covers PowerShell features that run on Windows 7, Windows Server 2008 R2 and later, PowerShell v3 and later, and includes v5 features like PowerShellGet.

about the technology

PowerShell is both a scripting language and an administrative shell that lets you control and automate nearly every aspect of Windows. It accepts and executes commands interactively and you can write scripts to manage most Windows servers like Exchange, IIS, and SharePoint, as well as online services like Azure and Office 365.

about the book

Источник

Learn Windows PowerShell in a Month of Lunches you own this product

placing your order.

Don’t refresh or navigate away from the page.

A seminal guide to PowerShell. Highly recommended.

Ray Booysen, BNP Paribas

Learn Windows PowerShell in a Month of Lunches is an innovative tutorial designed for busy administrators. Author Don Jones brings many years of successful training techniques to this concise, easy-to-follow book. Just set aside one hour a day—lunchtime would be perfect—for a month, and you’ll be automating administrative tasks faster than you ever thought possible.

about the technology

Windows has so many control panels, consoles, APIs, and wizards it’s really hard to keep track of all the locations and settings you’ll need. PowerShell is a godsend: it provides a single, unified administrative command line. It accepts and executes commands immediately. And it has in-built language features that will let you write scripts to control any Windows component, including servers like Exchange, IIS, and Sharepoint.

about the book

Learn Windows PowerShell in a Month of Lunches is a newly designed tutorial for system administrators. Just set aside one hour a day—lunchtime would be perfect—for a month, and you’ll be automating administrative tasks in a hurry. Author Don Jones combines his in-the-trenches experience with a unique teaching style to help you master the effective parts of PowerShell quickly and painlessly.

Источник

Learn PowerShell Scripting in a Month of Lunches you own this product

placing your order.

Don’t refresh or navigate away from the page.

A very clear and concise depiction of the best parts of PowerShell.

Justin Coulston, Intellectual Technology

GET MORE WITH MANNING

An eBook copy of the previous edition, Learn PowerShell Toolmaking in a Month of Lunches, is included at no additional cost. It will be automatically added to your Manning account within 24 hours of purchase.

Discover how scripting is different from command-line PowerShell, as you explore concrete hands-on examples in this handy guide. The book includes and expands on many of the techniques presented in Learn PowerShell Toolmaking in a Month of Lunches.

about the technology

Automate it! With Microsoft’s PowerShell language, you can write scripts to control nearly every aspect of Windows. Just master a few straightforward scripting skills, and you’ll be able to eliminate repetitive manual tasks, create custom reusable tools, and build effective pipelines and workflows. Once you start scripting in PowerShell, you’ll be amazed at how many opportunities you’ll find to save time and effort.

about the book

Источник

Learn Windows PowerShell 3 in a Month of Lunches

Learn Windows PowerShell 3 in a Month of Lunches, Second Edition is an innovative tutorial designed for administrators. Just set aside one hour a day—lunchtime would be perfect—for a month, and you’ll be automating Windows tasks faster than you ever thought possible. You’ll start with the basics—what is PowerShell and what can you do with it. Then, you’ll mov About the Book

Learn Windows PowerShell 3 in a Month of Lunches, Second Edition is an innovative tutorial designed for administrators. Just set aside one hour a day—lunchtime would be perfect—for a month, and you’ll be automating Windows tasks faster than you ever thought possible. You’ll start with the basics—what is PowerShell and what can you do with it. Then, you’ll move systematically through the techniques and features you’ll use to make your job easier and your day shorter. This totally revised second edition covers new PowerShell 3 features designed for Windows 8 and Windows Server 2012.

Purchase of the print book comes with an offer of a free PDF, ePub, and Kindle eBook from Manning. Also available is all code from the book.

Learn PowerShell from the beginning—no experience required! Covers PowerShell 3, Windows 8, and Windows Server 2012 Each lesson should take you one hour or less

About the Technology

PowerShell is both a language and an administrative shell with which you can control and automate nearly every aspect of Windows. It accepts and executes commands immediately, and you can write scripts to manage most Windows servers like Exchange, IIS, and SharePoint.

Experience with Windows administration is helpful. No programming experience is assumed.

Источник

Anyone own Learn Windows PowerShell in a Month of Lunches?

What are the first three command lines in it (and do they work)?

CLARIFICATORY EDIT: I’ve no doubt that these first three commands the reviewer refers to do actually work, I just want to know what they are, because I doubt very much they’ll be anything complicated that even could «fail»!

Edited Nov 4, 2016 at 10:55 UTC

The help desk software for IT. Free.

Track users’ IT needs, easily, and with only the features you need.

It’s a great book and has helped me immeasurably.

Don’t know the 1st 3 commands off the top of my head but I’m going to have a look now.

Edit: First one I can see it ‘get-help’. Works great.

Not sure who wrote this review, but this book is generally regarded as the best Powershell book you can get to learn PS.

I have it.. loads of other spiceheads have it. not sure what this review is on about.

do you have the full link to page? EDITED, found below

It’s like everything else, you’ll get as much out of it as you put in.

Follow along typing away blindly and you won’t learn much but put the necessary time and effort into thinking about the material and understanding it and it’ll be a big help. Definitely follow the format and do a chapter a day, don’t rush ahead. Let the chapter sink in before moving on.

It’s like everything else, you’ll get as much out of it as you put in.

Follow along typing away blindly and you won’t learn much but put the necessary time and effort into thinking about the material and understanding it and it’ll be a big help. Definitely follow the format and do a chapter a day, don’t rush ahead. Let the chapter sink in before moving on.

(Though I appreciate your comments were essentially rhetorical)

Seems to me that the reviewer didn’t even finish the first chapter, let alone put any effort in to it.

google on youtube don jones toolmaking 3 parts this is the guy that wrote the book

NetAdminWorld is an IT service provider.

I have it and used it. I think its fine, however I do wish they would put out an updated version to cover PS Version 5. I know there isn’t much difference between version 4 and 5, but it would be nice anyway; just my opinion.

No matter what flavor of PS you are running though, this book will give you some solid foundation. I agree with what TacticalNuclearSpud stated about getting as much out of it as you put into it. If you follow along at the pace YOU are comfortable with, you will get more out of it than you think.

google on youtube don jones toolmaking 3 parts this is the guy that wrote the book

I was merely curious as to how on earth the reviewer managed to get the «first three command lines» to fail!

I suspect he was typing them in to a command prompt rather than a Powershell console.

It’s like everything else, you’ll get as much out of it as you put in.

Follow along typing away blindly and you won’t learn much but put the necessary time and effort into thinking about the material and understanding it and it’ll be a big help. Definitely follow the format and do a chapter a day, don’t rush ahead. Let the chapter sink in before moving on.

(Though I appreciate your comments were essentially rhetorical)

Seems to me that the reviewer didn’t even finish the first chapter, let alone put any effort in to it.

Lol, yeah that was more of a rant at the reviewer than anything else. I get the rage when I see stuff like that. I want to find who wrote it and be like «You’re doing it wrong». It was written almost 2 years ago tho, they might have figured it out by now 🙂

I have it and used it. I think its fine, however I do wish they would put out an updated version to cover PS Version 5. I know there isn’t much difference between version 4 and 5, but it would be nice anyway; just my opinion.

No matter what flavor of PS you are running though, this book will give you some solid foundation. I agree with what TacticalNuclearSpud stated about getting as much out of it as you put into it. If you follow along at the pace YOU are comfortable with, you will get more out of it than you think.

NetAdminWorld is an IT service provider.

Lol, yeah that was more of a rant at the reviewer than anything else. I get the rage when I see stuff like that. I want to find who wrote it and be like «You’re doing it wrong». It was written almost 2 years ago tho, they might have figured it out by now 🙂

IMHO, he is only using this to defend his own lack of skills in PS and in feeling inadequate in this lack of skills must lash out at others who have these skills.

Lol, yeah that was more of a rant at the reviewer than anything else. I get the rage when I see stuff like that. I want to find who wrote it and be like «You’re doing it wrong». It was written almost 2 years ago tho, they might have figured it out by now 🙂

IMHO, he is only using this to defend his own lack of skills in PS and in feeling inadequate in this lack of skills must lash out at others who have these skills.

Maybe he just doesn’t like Don Jones.

NetAdminWorld is an IT service provider.

I have it and used it. I think its fine, however I do wish they would put out an updated version to cover PS Version 5. I know there isn’t much difference between version 4 and 5, but it would be nice anyway; just my opinion.

No matter what flavor of PS you are running though, this book will give you some solid foundation. I agree with what TacticalNuclearSpud stated about getting as much out of it as you put into it. If you follow along at the pace YOU are comfortable with, you will get more out of it than you think.

It’s a good book which teaches the basics. It’s mainly aimed at the core of PowerShell (V3). If you KNOW PowerShell v3, the additions in 4/5/5,1 are easy.

Yeah they had a free download of it a while back but I think that is over.

First 3 commands, huh? Let’s see.

Page 7 under the Note subsection, «The Powershell ISE isn’t preinstalled on server operating systems. If you want to use it, you’ll need to go in to Windows Features (using Server Manager) and manually add the ISE feature (you can also open the Powershell console and run Add-WindowsFeature powershell-ise).»

I had to go at this in a roundabout way. Since I’m not running a server OS on my desktop, I had to run the commands on a remote system. Also, since the feature was already installed, I could only prove that the feature exists and that the command is valid. Regardless, I’m going to say that it works.

Page 17 under the Try It Now subsection, this is just a repeat of the Page 6 command. So, I;m not going to count this one.

Page 18 under the Tip subsection, «From PowerShell, run Add-WindowsFeature powershell-v2 to install the v2 engine if you need it.»

Had to do this one the same way as the previous add-windowsfeature command. But we know the command is valid. So, here’s the proof that the feature exists, too.

Now, let’s assume that the reviewer did not mean commands in a subsection, but rather commands in the main text body. Those commands are help get-service (page 22), update-help (page 22), and help *log* (page 23). Here they are:

NOTE: I had to catch this one mid-command as there was not output to capture. Spoiler-alert: it worked.

Источник

Windows PowerShell: Курс выживания при создании сценариев

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

Если вы не привыкли к выполнению команд Windows PowerShell в консоли, потому что это кажется вам слишком сложным, пусть это и тяжело, все равно попытайтесь освоить их. Надо иметь хорошее представление о функциях безопасности Windows PowerShell. Вы должны знать о политике выполнения и о том какие параметры вы используете. Если вы еще не знаете разницу между RemoteSigned и AllSigned, а также почему одна из этих политик может быть лучше другой, скорее всего вы не готовы к чтению нижеследующего материала.

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

Если вам кажется, что вы недостаточно подготовлены, могу посоветовать почитать мою книгу «Learn Windows PowerShell in a Month of Lunches» (Manning Publications, 2011) и веб-сайт по теме, — возможно эти ресурсы помогут вам усвоить больше базовой информации.

Можете пользоваться этими ресурсами в процессе чтения статьи. Попытайтесь выполнить примеры. Если ввести (или скопировать) примеры сценариев в среду Windows PowerShell ISE, начиная со строки, тогда номера строк будут совпадать с номерами строк в описаниях.

Файлы сценариев Windows PowerShell

Файл сценария Windows PowerShell представляет собой простой текстовый файл с расширением .PS1. Единица указывает на версию не Windows PowerShell, а скорее версию обработчика языка. В Windows PowerShell версий 1 и 2 используется обработчик языка версии 1. Поэтому обе версии оболочки устанавливаются в подпапку v1.0 папки WindowsSystem32WindowsPowerShell.

Сценарий Windows PowerShell не совсем похож на командный файл для командной строки, кроме того выполнение сценария не совсем то же самое, что вводить вручную те же команды в той же последовательности. Например, откройте окно консоли и выполните следующее, нажимая Enter после каждой строки:

1. Get-Service
2. Get-Process

А теперь введите точно такие же команды в файл сценария или в панель редактирования сценариев в ISE и выполните сценарий. Результаты будут отличаться. При каждом нажатии Enter в Windows PowerShell вы запускаете новый конвейер. Все вводимые вами команды выполняются в одном конвейере. В конце существования конвейера Windows PowerShell преобразует его содержимое в текст на экране. При выполнении этих двух команд в обычной консоли это происходит в двух разных конвейерах.

Windows PowerShell смогла создать уникальные результаты работы для каждого набора выходных данных. С другой стороны, при запуске в составе сценария обе команды выполняются в одном конвейере. Система форматирования Windows PowerShell не настолько изощренна, чтобы создавать отдельные наборы выходных данных для двух результатов. Попытайтесь выполнить это в консоли:

1. Get-Service;Get-Process

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

Практический вывод из всего может заключаться в том, что сценарий должен возвращать выходные данные только одного вида. Это плохая идея по причине ограничений системы форматирования. Есть также другие соображения. Не нужно, чтобы сценарий одновременно сбрасывал в конвейер разнородные данные.

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

Переменные

Переменные следует считать чем-то вроде ящика, в который можно положить одну или несколько вещей, даже разнородных. У ящика есть имя, и в Windows PowerShell это имя может содержать практически любые символы. Именем переменной может быть как «Var», так и «{my variable}». Во втором примере имя переменной заключено в фигурные скобки, потому что оно содержит пробелы; выглядит это не очень красиво. Рекомендую все-таки использовать в именах переменных только буквы, цифры и подчеркивания.

При использовании имени переменной ссылаются на сам «ящик». Если нужно сослаться на содержимое ящика, используйте знак доллара, например, так: $var. В Windows PowerShell вам часто будут встречаться переменные со знаком доллара, так как весь смысл в его использовании заключается в получении содержимого переменных. Вместе с тем, надо помнить, что знак доллара не является частью имени переменной. Это всего лишь подсказка для Windows PowerShell, что вам требуется содержимое, а не сам ящик. Вот несколько примеров:

1. $var = ‘hello’
2. $number = 1
3. $numbers = 1,2,3,4,5,6,7,8,9

В примерах показано, как назначать переменным значения с использованием оператора присвоения (=). В последнем примере создается массив, потому что Windows PowerShell интерпертирует разделенные запятыми списки как массивы, или наборы элементов. В первом примере присваивается объект, представляющий собой строку, а вся строка заключается в кавычки.

Есть одна особенность Windows PowerShell, которая может вводить в заблуждение новичков. Windows PowerShell не «понимает», какой смысл связывается с именем переменной. Имя $computername не «говорит» оболочке, что в переменной хранится имя компьютера.

Аналогично имя $numbers не говорит оболочке, что переменная будет содержать более одного числа. Оболочке также все равно, какое число вы используете, — единственное или множественное. Для оболочки следующее выражение:

1. $numbers = 1

…правильное и ничем не отличается от такого:

1. $numbers = ‘fred.’

Вместе с тем, если переменная содержит несколько значений, для получения одного из них можно задействовать специальный синтаксис. Чтобы получить первый элемент, нужно использовать выражение $numbers[0], второй — $numbers[1], а последний элемент изображается так: $numbers[-1], предпоследний — $numbers[-2] и так далее.

Кавычки

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

Во-первых, это делают, когда нужно вставить содержимое переменной в строку. Только при наличии двойных кавычек Windows PowerShell будет искать знак «$» и предполагать, что все, что следует после этого знака и до первого символа, который не может быть частью имени переменной, является именем переменной. Вместо знака доллара с именем переменной будет вставлено ее содержимое.

1. $name = ‘Don’
2. $prompt = «My name is $name»

Переменная $prompt содержит строку «My name is Don», потому что $name заменяется содержимым этой переменной. Это замечательный прием — соединение строк вместо их конкатенации.

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

1. $debug = «`$computer contains $computer»
2. $head = «Column`tColumn`tColumn»

В первом примере первый знак доллара $ отменяется. Обратная кавычка отменяет его значение как аксессора переменной. Если переменная $computer содержит строку «SERVER», тогда в $debug будет содержаться такая строка: «$computer contains SERVER».

Во втором примере «`t» представляет собой символ табуляции, поэтому Windows PowerShell разместит между словами Column знаки табуляции. Подробнее об управляющих символах см. веб-страницу.

Наконец, двойные кавычки используются, когда строка должна содержать одинарные кавычки:

1. $filter1 = «name=’BITS'»
2. $computer = ‘BITS’
3. $filter2 = «name=’$computer'»

В этом примере создается строка «name=’BITS’». Все необходимое заключается в двойные кавычки. В $filter1 и $filter2 содержится одно и то же, но в $filter2 значение задается с использованием уловкой с заменой переменной в двойных кавычках. Заметьте, что значение имеет только самая «внешняя» пара кавычек. Одинарные кавычки оболочку Windows PowerShell не интересуют. Эти одинарные кавычки представляют собой простые литеральные символы. Windows PowerShell их не интерпретирует.

Члены и переменные объектов

В Windows PowerShell все состоит из объектов. Даже простая строка, такая как «name», является объектом типа System.String. Чтобы узнать тип объекта (то есть, что представляет собой объект), а также его членов, к которым относятся его свойства и методы, достаточно передать объект в Get-Member по конвейеру:

1. $var = ‘Hello’
2. $var | Get-Member

Используйте точку после имени переменной, чтобы сказать оболочке: «Мне не нужен доступ ко всему объекту в переменной, а только к одному из его свойств или методов». После точки укажите нужное свойство или имя метода.

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

1. $svc = Get-Service
2. $svc[0].name
3. $name = $svc[1].name
4. $name.length
5. $name.ToUpper()

Обратите внимание на вторую строчку. Она начинается с обращения к первому элементу переменной $svc. Точка означает, что нам не нужен весь объект, а только его свойство или метод. В данном случае нужно свойство name. В пятой строке показано, как обращаться к методу, указывая его имя после точки, а также пару скобок.

Обычно точка в именах переменных не используется, так как она отделяет свойство или метод.  Это означает, что вторая строка в следующем примере будет делать не то, что ожидалось:

1. $service = ‘bits’
2. $name = «Service is $service.ToUpper()»
3. $upper = $name.ToUpper()
4. $name = «Service is $upper»

На второй строке $name содержит«Service is BITS.ToUpper()», а в четвертой строке — «Service is BITS».

Скобки

Помимо указания на методы объектов, скобки также служат в Windows PowerShell маркерами, определяющими порядок выполнения, — как в обычных алгебраических выражениях. Иначе говоря, скобки указывают оболочке, что нужно выполнять в первую очередь. Выражение в скобках заменяется тем, что получается в результате вычисления этого выражения. Вот несколько задачек на сообразительность:

1. $name = (Get-Service)[0].name
2. Get-Service -computerName (Get-Content names.txt)

В первой строке $name содержит имя первой службы в системе. Чтобы понять этот пример, придется немного напрячь мозги. Начнем с выражения в скобках. Windows PowerShell начнет анализ именно с этого места. Get-Service разрешается в набор, или массив, служб. Выражение [0] позволяет получить первый элемент массива, которым будет первая служба. Так как за этим следует точка, мы знаем, что идет обращение к свойству или методу этой службы, а не ко всему объекту. Наконец мы извлекаем только имя службы.

Во второй строке выражение в скобках читает содержимое текстового файла. Если файл содержит имена компьютеров — по одному в строке, Get-Content вернет массив имен компьютеров. Они передаются в параметр –computerName командлета Get-Service. В данном случае оболочка передаст результат любого выражения в скобках, возвращающего массив строк, в параметр –computerName, потому что последний создан принимать массивы строк.

Область действия

Область действия — это понятие в программировании, служащее в качестве системы «контейнеризации». Такие вещи как переменные, псевдонимы, диски и другие элементы Windows PowerShell, все хранятся в области действия. Оболочка поддерживает иерархию областей действия и определяет ряд правил, определяющих порядок взаимодействия и обмена информацией между областями действия.

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

По окончании работы сценария его область действия отбрасывается, а все созданное в ней исчезает. Например, создайте следующий сценарий и выполните его в окне консоли:

1. New-PSDrive -PSProviderFileSystem -Root C: -Name Sys
2. Dir SYS:

После выполнения сценария вручную выполните команду Dir SYS:. Вы получите ошибку. Причина в том, что диск SYS: был создан в сценарии. По окончании работы сценария все им созданное было уничтожено. Диск SYS: больше не существует. Не все в оболочке работает в собственном диапазоне. Такие элементы, как модули всегда обрабатываются глобально. Модуль, загруженный сценарием, остается таковым по окончании работы сценария.

Если в области действия предпринимается попытка обратиться к чему-то, что не было создано в ней, Windows PowerShell обращается к следующей области действия более высокого уровня («родительской»). Вот почему псевдоним Dir сработал в созданном вами сценарии. Хотя Dir не существовал в области действия сценария, он существовал в области действия более высокого уровня — в глобальной области действия. В области действия можно создавать элементы с именами, которые существуют в области более высокого уровня. Вот еще один сценарий для выполнения:

1. Dir
2. New-Alias Dir Get-Alias
3. Dir

Это кажется странным, но при первом выполнении Dir каталог не существовал в области действия сценария. Был использован псевдоним Dir более высокого уровня. Этот псевдоним указывает на Get-ChildItem, поэтому было показано знакомое содержимое каталога.

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

В областях действия особенно легко запутаться, когда речь идет о переменных. Как правило, из определенной области действия никогда не следует обращаться к элементам за ее пределами, особенно к переменным. Есть синтаксис для выполнения таких операций, например можно использовать $global:var для принудительного обращения к переменной $var глобальной области действия, но это очень плохой способ, применение которого допустимо только в очень специфических обстоятельствах.

Язык сценариев Windows PowerShell

Windows PowerShell содержит очень упрощенный язык сценариев, который состоит менее чем из двух дюжин слов. Он сильно отличается от полноценного языка программирования, такого как VBScript, который содержит почти три сотни слов.

Несмотря на свою простоту, язык Windows PowerShell более чем эффективен для своих задач. Сейчас я расскажу об основных сценарных конструкциях, но вы всегда можете получить более подробные сведения, обратившись к соответствующей about-статье в оболочке. Например, help about_switch содержит информацию о конструкции Switch, а help about_if —о конструкции If. Чтобы получить список всех about-статей, выполните команду help about*.

Конструкция If

Это основная конструкция Windows PowerShell для принятия решений. Полная ее форма выглядит так:

1. If ($this -eq $that) {
2.   # commands
3. } elseif ($those -ne $them) {
4.   # commands
5. } elseif ($we -gt $they) {
6.   # commands
7. } else {
8.   # commands
9. }

Ключевое слово «If» является обязательной частью конструкции. Результат вычисления следующего за ним выражения должен быть True или False. Windows PowerShell всегда интерпретирует ноль как False, а любое ненулевое значение как True.

Windows PowerShell также различает встроенные переменные $True и $False, которые представляют указанные булевы значения. Если выражение в скобках равно True, тогда выполняются команды в следующих далее фигурных скобках. Если выражение равно False, эти команды не выполняются. Это минимально необходимый состав конструкции If.

Можно пойти чуть дальше, задав один или больше разделов ElseIf. Они работают так же, как и конструкция If. У них есть собственное выражение в скобках. Если оно равно True, выполняются команды в следующих за выражением фигурных скобках. В противном случае команды не выполняются.

Завершить конструкцию можно блоком Else, который выполняется, если не выполнился ни один из предыдущих блоков команд.  Выполнится только первый блок команд, для которого выражение в скобках равно True. Например, если $this не равно $that, а $those не равно $them, тогда будут выполнены только команды в четвертой строке. Windows PowerShell даже не станет вычислять выражение для elseif в пятой строке.

Символ «решетка» (#) служит для выделения комментариев, то есть Windows PowerShell игнорирует весь текст от этого символа до следующего возврата каретки. Также обратите внимание на аккуратное форматирование описанных конструкций. Некоторые форматируют текст так:

1. if ($those -eq $these)
2. {
3.   #commands
4. }

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

В среде Windows PowerShell ISE для этой цели можно использовать клавишу Tab, при нажатии которой по умолчанию делается отступ размеров в четыре пробела. Отступы в коде — это базовое требование к написанию кода. Если этого не делать, в объемных сценариях будет очень сложно не ошибиться при расстановке фигурных скобок. Ну и не стоить говорить, что даже новички Windows PowerShell будут насмехаться над вашим текстом без отступов. Посмотрите на этот плохо форматированный сценарий:

1. function mine {
2. if ($this -eq $that){
3. get-service
4. }}

Его намного сложнее читать, отлаживать, устранять неполадки и поддерживать. Хотя пробелы после закрывающей скобки не нужны, они делают сценарий проще для чтения. Отступы в коде не являются необходимыми, но при их наличии код намного легче понимать. Посмотрите на тот же код в другом виде:

1. function mine {
2.  if ($this -eq $that){
3.   get-service
4.  }
5. }

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

Конструкция Do While

Это конструкция цикла в Windows PowerShell. Она служит для многократного выполнения блока команд, пока условие равно True или не станет True. Вот самый простой случай:

1. Do {
2.   # commands
3. } While ($this -eq $that)

В этом варианте конструкции команды в фигурных скобках выполнятся по крайней мере один раз. Условие While вычисляется не ранее, чем первый раз выполнится блок команд. Можно перенести While — тогда команды будут выполнены, только если с самого начала условие равно True:

1. While (Test-Path $path) {
2.   # commands
3. }

Заметьте, что во втором примере не используется оператор сравнения, например -eq. Причина в том, что командлет Test-Path по определению возвращает True или False, поэтому для нормальной работы выражения эти значения не нужно ни с чем сравнивать.

Выражение в скобках в этой конструкции вырождается до простого значения True или False. Именно это происходит, когда вы используете команду, которая всегда возвращает True или False, например Test-Path. Как всегда, есть соответствующая about-статья, где можно найти другие примеры использования этой конструкции.

Конструкция ForEach

Работа этой конструкции похожа на поведение командлета ForEach-Object. Различия только в синтаксисе. Задача ForEach — принять массив (или набор, что в Windows PowerShell равносильно массиву) и выполнить его перечисление, чтобы можно было каждый раз работать с одним объектом:

1. $services = Get-Service
2. ForEach ($service in $services) {
3.   $service.Stop()
4. }

Новички могут очень легко запутаться с этой конструкцией. Помните, что множественное число слова «services» в английском для Windows PowerShell ничего не значит. Переменная называется именно так, чтобы напоминать, что содержит одни или несколько служб. Если это множественное число, то это не значит, что оболочка будет как-то особо его обрабатывать.

Ключевое слово «in» во второй строке является частью синтаксиса ForEach. Имя $service — это просто произвольное имя переменной. С таким же успехом в этом месте могло быть им $fred или $coffee.

Windows PowerShell будет повторно выполнять команды в фигурных скобках по отношению к каждому очередному объекту во второй переменной ($services). Каждый раз оболочка будет принимать один объект из второй переменной ($services) и помещать его в первую переменную ($service).

В конструкции первую переменную ($service) нужно использовать как содержащую единичный объект. В третьей строке точка означает, что нужен не весь объект, а только один из его членов — метод Stop.

Иногда бывает так, что использование ForEach желательно и даже неизбежно. Однако если у вас уже есть опыт программирования, вы можете прибегать к ForEach, когда этого лучше не делать. В предыдущем примере лучше не использовать ForEach. Разве не проще сделать так:

1. Get-Service | Stop-Service

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

• Когда нужно выполнить метод по отношению к набору объектов и нет командлета, который бы мог выполнить эту задачу.
• Если есть набор объектов и по отношению к каждому нужно выполнить ряд последовательных операций.
• Когда операцию нужно выполнять только по отношению к одному объекту за раз, но в процессе выполнения сценария количество объектов — один или несколько — заранее неизвестно.

Другие конструкции

В Windows PowerShell есть ряд других конструкций, в том числе Switch, For и другие. Они описаны в about-статьях оболочки. Иногда их можно заменять уже описанными конструкциями. Например, можно заменить Switch конструкцией If с несколькими разделами ElseIf. For можно заменить ForEach или даже командлетом ForEach-Object. Вот пример цикла, который выполняется ровно десять раз:

1. 1..10 | ForEach-Object -process {
2.   # code here will repeat 10 times
3.   # use $_ to access the current iteration
4.   # number
5. }

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

Функции

Функция — это особый вид конструкции, служащий для объединения группы взаимосвязанных команд для выполнения одной четко определенной задачи. Вообще говоря, можно взять любой сценарий Windows PowerShell и «обернуть» его в функцию:

1. function Mine {
2.   Get-Service
3.   Get-Process
4. }
5. Mine

Здесь определена новая функция по имени Mine. Это, в сущности, превращает Mine в команду, так как запустить функцию можно, просто указав ее имя. Именно это и происходит в пятой строке.

Функции обычно располагают в файлах сценариев. Один сценарий может содержать несколько функций. А функции могут содержать в себе другие функции.

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

1. function One {
2.   function Two {
3. Dir
4.   }
5.   Two
6. }
7. One
8. Two

Представьте, что вы разместили этот текст в файле сценария и выполнили его. В седьмой строке выполняется функция One, определение которой начинается на первой строке. В пятой строке выполняется функция Two, определение которой начинается на пятой строке. Поэтому в результате получим список содержимого каталога — соответствующая команда размещена на третьей строке в функции Two.

Но следующая выполняемая строка (номер восемь) приведет к ошибке. В сценарии нет функции по имени Two. Функция Two спрятана в функции One. Поэтому функция Two существует только в области действия функции One и видна только из последней. Попытка вызвать Two из любого другого места приведет к ошибке.

Параметры в сценарии

Редко сценарии создаются для выполнения в точности одной и той же задачи при каждом запуске. Чаще сценарии содержат изменяемые данные или их поведение может меняться в зависимости от входных данных. Эти вариации можно реализовать с помощью параметров.

Параметры определяются особым образом вначале сценария. Можно предварить это определение комментарием, но в любом случае это должна быть первая исполняемая строка сценария. В области определения параметров каждый из них отделяется запятой. Для удобства чтения каждый параметр рекомендуется располагать в собственной строке. Вот пример:

1. param (
2.   [string]$computername,
3.   [string]$logfile,
4.   [int]$attemptcount = 5
5. )

Здесь определяются три параметра. В сценарии они используются как любые другие переменные. Вы наверняка заметили, что в пятой строке я присвоил параметру $attemptcount значение по умолчанию. Это значение будет заменено значением входного параметра, но если он не будет задан, сценарий будет выполняться со значением по умолчанию.

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

1. ./test -computername SERVER
2. ./test -comp SERVER -log err.txt -attempt 2
3. ./test SERVER err.txt 2
4. ./test SERVER 2
5. ./test -log err.txt -attempt 2 -comp SERVER

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

• В первой строке я задал только один из параметров, поэтому $logfile будет пустым, а $attemptcount будет содержать 5, значение по умолчанию.
• Во второй строке я задал все три параметра, но при этом использовал сокращенные имена. Как и в командлетах, достаточно задать только начало имени параметра, которого достаточно для того, чтобы оболочка Windows PowerShell «поняла», о чем идет речь.
• В третьей строке снова заданы все три параметра, но теперь они заданы по позициям, без использования имен параметров. Насколько я помню, если параметры задавать точно в том порядке, в каком они определены в сценарии, все работает нормально.
• В четвертой строке показано, что происходит, если не соблюдать осторожность. Здесь $computername получит значение «SERVER», $logfile будет содержать 2, а $attemptcount — 5. Это не совсем то, что мне было нужно. Если не использовать имена параметров, теряется гибкость. Также посторонним людям становится сложнее понять, что вы имели в виду, а это в свою очередь усложняет устранение возможных неполадок.
• В пятой строке приведен лучший пример. Здесь я указал параметры не в том порядке, в котором они определены, но это не страшно, потому что я указал их имена. В общем случае рекомендуется использовать имена параметров — это дает дополнительную гибкость. Вам не нужно будет помнить порядок, в котором они определены.

Более сложные сценарии

Windows PowerShell предоставляет возможность предоставлять дополнительную информацию о параметрах. Можно определить параметр как обязательный, принимающий входные данные из конвейера и т. п. Этот прием называется привязкой командлетов.

При этом механизм использования параметров в сценарии не меняется. Просто оболочке предоставляется чуть больше информации о параметрах. Этот прием чаще всего используется в функциях, но в сценариях этот синтаксис также допустим. Вот простой пример:

1. [CmdletBinding()]
2. param (
3.   [Parameter(Mandatory=$True)]
4.   [string]$computername,
5.   [Parameter(Mandatory=$True)]
6.   [string]$logfile,
7.   [int]$attemptcount = 5
8. )

Я добавил всего лишь инструкцию [CmdletBinding()] в первой исполняемой строке кода в сценарии. Перед этой строкой не разрешается ничего размещать кроме комментариев. Я также присоединил к своим двум параметрам инструкцию [Parameter()], где указал, что они обязательны. Теперь если кто-то попытается выполнить сценарий, не задав эти параметры, Windows PowerShell предложит ввести эту информацию.

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

Это было очень быстрое введение по теме создания сценариев в Windows PowerShell. Я надеюсь, что из этой статьи вы почерпнули что-то полезное. Создание параметризованных сценариев — особенно полезная функциональность, потому что позволяет создавать сценарии, которые выглядят и ведут себя так же, как и настоящие командлеты Windows PowerShell.