Powershell on error resume next

Avoiding «ON ERROR RESUME NEXT» when Using Powershell

In Powershell and the Principle of Most Astonishment, I covered some of the surprises that new Powershell users encounter when trying to reliably return results from functions. The next area where Powershell suprises new users is in its approach to error handling. Fortunately, there are some useful workarounds for making the surprising default behavior work more like you would expect.

While learning Powershell, I was trying to create a deployment script. The script needed to perform several tasks including, copying the deployment package to the target machine, setting up services, and the like. While testing it out locally, I would deliberately cause certain steps to fail in order to ensure that the user of the script would be clearly alerted to failures. To my surprise, when I caused exceptions to be thrown, the script would happily continue on to the next step, ultimately printing a success message to the user. Consider this example:

What the heck just happened? If you can’t rely on uncaught exceptions to stop execution, how can you reliably deal with failures? What if we throw an exception and then blindly move along to a subsequent step that depends on the success of previous steps?

Powershell reintroduces VB’s “ON ERROR RESUME NEXT”, but goes one step further by making it the default! Abandon all hope, ye who etc, etc.

To make Powershell error handling work more like error handling in other .NET languages, we can set $global:ErrorActionPreference = “Stop” at the start of our script. With this variable set, uncaught exceptions thrown by Powershell code will cause the whole script to stop. Altering our example with this line, we get the output that we originally expected:

This solves most of our problem: the behavior of Powershell code that throws errors. Unfortunately, it doesn’t help us when we invoke an external executable that fails in the middle of our script. In my next post, I’ll show you how to address the failure of external executables.

Источник

Hey, Scripting Guy! How Can I Use $ErrorActionPreference to Control Cmdlet Handling of Errors?

Hey, Scripting Guy! One thing I liked about using VBScript is that I could add On Error Resume Next to the top of a script, and all my problems with the script went away. It was like magic, and I used it to fix many of my scripts. I really miss this capability in Windows PowerShell.

Hello MW,

Microsoft Scripting Guy Ed Wilson here. It is Monday morning. Generally, I love Mondays. Although if the truth were told, they are not that much different from Saturdays or Thursdays. A day of scripting is after all a day of scripting, and that means they are all good! Those of you who follow the Scripting Guys on Twitter or Facebook know that you are quite likely to find either Craig or me hanging out over the weekend. This weekend was a bit different. I have been in contact with a professional woodworker who studied with James Krenov at the College of the Redwoods . We sent e-mail back and forth, and he agreed to give me private lessons in his studio. It made for an excellent weekend, but because his studio is several hundred miles away, I am a bit tired this morning. In fact, this morning is an unplanned coffee morning . I have my French press sitting beside my Zune HD, and I am sipping a cup of Peaberry Kona coffee from Kauai, which has a rich, nutty taste with hints of cherry and nutmeg. Whereas I normally put a cinnamon stick in a cup of coffee (a habit I picked up while I was teaching VBScript in Lisbon, Portugal), I feel to do so with this excellent coffee would almost be an insult. The same is true of loading it down with sugar and milk. Therefore, I drink this coffee unadorned. Speaking of Kauai, in addition to having excellent coffee, there is great scuba diving there. The following photograph is one I took during a trip there.

MW, you can achieve something similar to On Error Resume Next by assigning the string SilentlyContinue to the $ErrorActionPreference automatic variable. The reason I say it is similar is that it does not hide all errors. For example, if I try to create an object that does not exist, such as the infamous foo, Windows PowerShell generates an error (in spite of all the examples of this in various programming books). The error seen here tells you it cannot find the type for foo, and that the assembly containing this type is not loaded:

PS C:> New-Object foo
New-Object : Cannot find type [foo]: make sure the assembly containing this type is loaded.
At line:1 char:11
+ New-Object foo
+ CategoryInfo : InvalidType: (:) [New-Object], PSArgumentException
+ FullyQualifiedErrorId : TypeNotFound,Microsoft.PowerShell.Commands.NewObjectCommand

To hide this error, set the value of the automatic variable $ErrorActionPreference to SilentlyContinue, as seen here:

PS C:> $ErrorActionPreference = “silentlycontinue”
PS C:> New-Object foo
PS C:>

This command does not suppress all errors. For example, if I generate a divide-by-zero error, an error appears. Windows PowerShell generates the error regardless of the setting for the $ErrorActionPreference automatic variable. The following code illustrates this:

PS C:> 1/0
Attempted to divide by zero.
At line:1 char:3
+ 1/ + CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : RuntimeException

PS C:> $ErrorActionPreference = silentlycontinue
The term ‘silentlycontinue’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:42
+ $ErrorActionPreference = silentlycontinue + CategoryInfo : ObjectNotFound: (silentlycontinue:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

The difference in behavior is because the $ErrorActionPreference automatic variable controls reporting from cmdlets and not system errors. In addition, it is i mportant to remember that the $ErrorActionPreference automatic variable is only valid for –not terminating errors. So what is the difference between a terminating error and a nonterminating error? A terminating error is raised by a cmdlet (by calling the ThrowTerminatingError method) when the error is so bad that the cmdlet would not be able to continue processing the pipeline or in some cases the entire script. Generally, these will be syntax errors.

A nonterminating error is one that is not so bad that it would halt the execution of the cmdlet or the script. For example, attempting to read a text file that does not exist does not mean that the Get-Content cmdlet will stop working. If you give it the path to a file that does exist, it will work just fine as shown here:

PS C:> Get-Content foo

Get-Content : Cannot find path ‘C:foo’ because it does not exist.

At line:1 char:12

+ CategoryInfo : ObjectNotFound: (C:foo:String) [Get-Content], ItemNotFoundException

Источник

Обработка ошибок в PowerShell (часть 1)

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

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

Get-Content -Path C:Filesservices.txt | Restart-Service

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

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

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

Обработка непрерывающих ошибок

Для получения ошибки возьмем службу с ″оригинальным″ названием Service. Поскольку службы этой на сервере нет, то обращение к ней стабильно будет генерировать ошибку. Запросим данные о нескольких службах командой:

Как видно из примера, PowerShell не нашел службу Service, о чем выдал ошибку и затем продолжил выполнение команды. Давайте разберемся, почему команда повела себя именно так и как это поведение изменить.

За поведение команды при возникновении ошибки отвечает параметр ErrorAction, который может принимать одно из пяти значений:

• Continue;
• SilentlyContinue;
• Stop;
• Ignore;
• Inquire.

Примечание. Еще у ErrorAction может быть значение Suspend. Но это значение может применяться только к рабочим процессам (workflows), поэтому в рамках данной статьи речь о нем не пойдет.

Значение Continue означает, что при возникновении ошибки информация об этом будет выведена на экран (отправлена в поток вывода Error) и добавлена в автоматическую переменную $Error, после чего выполнение команды будет продолжено. Надо сказать, что Continue — это действие, определенное в сеансе по умолчанию, поэтому его можно не указывать явно.

При значении SilentlyContinue информация об ошибке добавляется в переменную $Error, но не выводится на экран. При этом команда продолжает выполняться дальше, также как и в предыдущем случае.

Значение Stop останавливает дальнейшее выполнение команды при возникновении ошибки. И наоборот, значение Ignore полностью игнорирует возникновение ошибки, при этом не выводится сообщение на экран и не производится запись в $Error. Это значение появилось в PowerShell 3.0.

Inquire — наиболее интересное значение ErrorAction. Если задать это значение, то при возникновении ошибки предлагается на выбор несколько действий: продолжить (Yes), продолжить не смотря на эту и все последующие ошибки (Yes to All), остановить (Halt) или приостановить (Suspend) выполнение команды.

Самый необычный эффект дает Suspend, при выборе которого открывается параллельный сеанс (Nested Namespace). Определить его можно по значку >>. Nested Namespace представляет из себя дочерний процесс, в котором можно полноценно работать — выполнять команды, запускать скрипты и т.п. Этот режим удобно использовать для отладки скриптов, например можно по быстрому исправить причину ошибки и продолжить выполнение. Для выхода из Nested Namespace достаточно набрать exit и выбрать необходимое действие.

Примечание. У параметра ErrorAction есть алиас — EA. Кроме того, вместо названия параметра можно указывать числовые значения: 0 (SilentlyContinue), 1 (Stop), 2 (Continue), 3 (Inquire). Так например, вместо:

Get-Service service,spooler -ErrorAction SilentlyContinue

можно написать так:

Get-Service service,spooler -EA 0

Переменные для обработки ошибок

Как я уже говорил, если не указывать параметр ErrorAction, то для команды действует режим обработки ошибок, определенный в сеансе. Этот режим задается переменной $ErrorActionPreference, которая по умолчанию имеет значение Continue. При желании можно переопределить режим для всего сеанса, задав переменной $ErrorActionPreference нужное значение.

Все ошибки PowerShell сохраняет в автоматическую переменную $Error. Это глобальная переменная, которая представляет из себя массив строк, содержащий записи обо всех ошибках в текущем сеансе. Каждая новая ошибка добавляется в начало массива, соответственно для просмотра последней ошибки надо обратиться к самому первому элементу массива $Error[0].

$Error имеет свои свойства и методы, которые можно использовать. Например, посмотреть общее количество ошибок в текущем сеансе можно командой $Error.Count, а очистить список — командой $Error.Clear().

Переменная $Error не безразмерна, по умолчанию она хранит не более 256 ошибок. При превышении этого количества наиболее старые ошибки будут затираться. При необходимости количество записей в переменной $Error можно увеличить, изменив значение другой переменной $MaximumErrorCount.

Кроме $Error для хранения ошибок допускается задавать собственные переменные. Сделать это можно с помощью параметра ErrorVariable, например так:

Get-Service service,spooler -ErrorAction SilentlyContinue -ErrorVariable var

Обратите внимание, что имя переменной в команде задается без знака $, хотя в дальнейшем к ней обращаемся как к обычной переменной $var.

В отличие от глобальной переменной $Error заданные вручную переменные хранят только ошибки той команды, в которой они определены. Кроме того, по умолчанию эти переменные каждый раз перезаписываются и поэтому хранят только последнюю ошибку. Если вы хотите, чтобы новые ошибки добавлялись в переменную, не перезаписывая ее содержимое, то перед именем переменной надо поставить знак +, например +var.

Пока все, а в следующей части пойдет о способах обработки прерывающих ошибок.

Источник

May 28th, 2010

(Note: These solutions were written for Beginner Event 10.)

Beginner Event 10 (Windows PowerShell)

Jonathan Medd is a Windows PowerShell MVP and co-host of the Get-Scripting podcast. He regularly posts about Windows PowerShell on his blog, http://jonathanmedd.net, and you can tune in to the monthly Windows PowerShell podcast at http://get-scripting.blogspot.com. You can follow his Windows PowerShell and other system administrator antics at https://twitter.com/jonathanmedd.

The first step in troubleshooting this script is to comment out the opening line:

#$errorActionPreference = “silentlycontinue”

The default value of $errorActionPreference in Windows PowerShell is continue. This means that upon hitting an error, Windows PowerShell will flag the error, but attempt to carry on processing the script. By commenting out the first line, which has changed the value of $errorActionPreference to silentlycontinue, we will be able to troubleshoot what is wrong with the script.

If we now run the script again we get the following error: “You cannot call a method on a null-valued expression as seen below.”

From the second line of the error, we can see that the issue is with line 4:

$Shell.popup($w.UserName)

The method is the part of the line after the dot so we know that for some reason the variable $Shell is empty. This is because in line 3, the variable used to store the wscript.shell ComObject has been named $wshShell. So to correct that, line 4 should look like this:

$wshShell.popup($w.UserName)

If we run the updated script again, we receive the below message box. No error this time, but it is empty. So we know that we can create a message box, but there must be something wrong with populating the text.

This is again partly to do with the naming of variables. In line 1, we used $wmi to store the results of the WMI query to retrieve the currently logged-on user. This is the variable we need to use in the popup method to display the correct text. So line 3 should be further corrected:

$wshShell.popup($wmi.UserName)

However, running the script again still returns an empty message box. Going back to the original WMI query in line 1, if we run it interactively we get the below result:

The value of the Name property is the name of the computer, not the logged on user. Also this property is not called UserName, which we are trying to use in line 4. By changing the WMI query to instead use the UserName property, we get the correct logged-on user:

Get-WmiObject -Class Win32_computerSystem -Property UserName

The corrected script now looks like this:

Beginner10_Fixed.ps1

#$errorActionPreference = “silentlycontinue”

$wmi = Get-WmiObject -Class Win32_computerSystem -Property UserName

$wshShell = New-Object -ComObject wscript.shell

$wshShell.popup($wmi.UserName)

When we run this corrected script, the following message box is displayed.

A slightly more advanced way to create a message box would be to use the message box class within the System.Windows.Forms .NET Framework namespace. While not providing much extra in this particular example, more complex forms could be created using these tools.

You first need to load the system.windows.forms assembly (only a subset of the .NET Framework is available by default in Windows PowerShell):

[reflection.assembly]::loadwithpartialname(‘system.windows.forms’) | Out-Null

Run the same WMI query as before:

$wmi = Get-WmiObject -Class Win32_computerSystem -Property UserName

Then use the show method of the system.windows.forms.messagebox class to display the message box:

[system.Windows.Forms.MessageBox]::show($wmi.username)

Beginner Event 10 (VBScript)

Georges Maheu is the Premier Field Engineer (PFE) Security Technology Lead for Microsoft Canada. As a Senior PFE, he focuses on delegation of authority (how many domain administrators do you really have?), server hardening, and doing security assessments using his own scripts. Georges has a passion for VBScript, Windows PowerShell, and WMI and uses them on a regular basis to gather information from Active Directory and computers. Georges also delivers popular scripting workshops to Microsoft Premier Customers worldwide.

————

VBScript solution

On Error Resume Next
Set wmi = GetObject(“winmgmts:”)
colitems = wmi.Execquery(“Select user from Win32_computersystem”)
For Each item In colitem
WScript.Echo item.username
Next

This is a classic: a script written by someone else without comments. In this situation, the first thing I do after examining the source code is to double-click the script in a test environment. Personally, I use Virtual PC for all my script development and testing. Never run a script in production until you fully and totally understand what it does.

Well, running this script did not help. Nothing seems to happen. My next reflex is to comment out the first line and to add the Option explicit statement to force variable declarations:

‘ On Error Resume Next ‘GLM: commented out
Option explicit ’GLM: added

The apostrophe character is used to add comments or descriptive text in a VBScript. In this case, it will prevent the error-handling statement On error resume next from executing. On error resume next makes your scripts ignore errors (no error messages either) and move on to the next line. I could have deleted the line but I like to keep the original code around while I debug. I also add comments preceded by my initials, GLM.

Now, when I run the script, I get this dialog box:

As a best practice, all variables should be declared, and adding the Option explicit statement makes this mandatory. Variables are declared with the Dim statement. I add the following:

Dim WMI

I then repeat the process until all the variables are declared:

Dim colItems
Dim item

During this process, I notice there is a typo in colItem. An s is missing at the end!

colItems = wmi.Execquery(“Select user from Win32_computersystem”)
‘ For Each item In colItem ‘original code
For Each item In colItems ‘GLM: modified

At this point, the code looks like this:

‘On Error Resume Next ‘GLM: commented out
Option explicit ‘GLM: added
Dim WMI ‘GLM: added
Dim colItems ‘GLM: added
Dim item ‘GLM: added
Set WMI = GetObject(“winmgmts:”)
colItems = WMI.Execquery(“Select user from Win32_computersystem”)
‘ For Each item In colItem ‘original code
For Each item In colItems ‘GLM: modified
WScript.Echo item.username
Next

And I get the following error message:

A search (using Bing) on “vbscript error 800A01C2” may give you an indication of what the problem could be. Fortunately, I found a webpage with a similar problem and remembered that the WMI ExecQuery requires a Set to work:

‘ colItems = wmi.Execquery(“Select user from Win32_computersystem”) ‘original code
Set colItems = wmi.Execquery(“Select user from Win32_computersystem”) ‘GLM: modified

Let’s run the code and see what happens.

OK, another error. And I thought this was going to be easy.

However, line #10 (For Each item In colItems) seems to be fine. One thing you learn quickly when you write or debug scripts is that errors sometimes occur in cascades. If you can’t find anything wrong with a particular line, it could be the error occurred in the code before the line in which the error was reported. The question is, where?

WMI, which stands for Windows Management Instrumentation, is in some respect Microsoft’s implementation of WBEM, a standard created by DMTF. WMI uses WQL, a query language similar to SQL. Knowing this, I decided to replace the WQL query with the following:

‘ colItems = WMI.Execquery(“Select user from Win32_computersystem”) ‘original code
Set colItems = WMI.Execquery(“Select * from Win32_computersystem”) ‘GLM: modified

I did this because the “*” is like a wild card character and will return all the properties associated with the Win32_computerSytem class. Unlike PowerShell, there is no simple way to list properties in VBScript. You could write some code (review Scriptomatic source code for an example), but this would probably be more work than debugging this code! Another option is to use CIM Studio from the free WMI tools.

CIM Studio will give you a complete list of all the properties and methods for a given class. With this information, I could also have rewritten the line to:

Set colItems = WMI.Execquery(“Select userName from Win32_computersystem”)

Let’s run the script one more time.

Yes! It works.

Here is the working script after our debugging session:

‘On Error Resume Next ‘GLM: commented out
Option explicit ‘GLM: added
Dim WMI ‘GLM: added
Dim colItems ‘GLM: added
Dim item ‘GLM: added
Set WMI = GetObject(“winmgmts:”)
‘ colitems = WMI.Execquery(“Select user from Win32_computersystem”) ‘original code
Set colItems = WMI.Execquery(“Select * from Win32_computersystem”) ‘GLM: modified
‘ For Each item In colItem ‘original code
For Each item In colItems ‘GLM: modified
WScript.Echo item.UserName
Next

I save this version as a reference and then clean the code. You will notice I removed the On Error Resume Next statement. Because I’m not doing any error handling, there is no point using this statement. Here is the final script with added comments:

ShowLoggedUserAccount.vbs

‘* File: ShowLoggedUserAccount.vbs
‘* Version: 1.06
‘* Date: 2010/04/06
‘* Author: Georges Maheu, Microsoft PFE
‘*
‘* Based on the original file
‘* File: VBScriptDoesNotWOrk.vbs
‘* Version: 1.0
‘* Date: 2010/03/21
‘* Author: John Doe
‘* Modifications: documented in file Debug-VBScriptDoesNotWOrk.vbs
‘
‘ This script will display the name of the current logged-on user
‘ on a local or remote computer
‘ ================================================================
Option Explicit ‘make variable declaration mandatory
Dim WMI ‘WMI service object
Dim colItems ‘collection of items returned by WMI query
Dim item ‘individual item from the WMI collection variable colItems
Dim computerName ‘name of computer to query
‘LocalHost can be replaced by a remote computer name or IP address
‘must be run from an account with sufficient permissions to see the data
computerName = “localhost”
‘create WMI service object and connect to CIMv2 namespace on computerName
Set WMI = GetObject(“winmgmts:\”+computerName+”rootCIMv2”)
‘retrieve userName property from Win32_computerSystem WMI class
set colItems = WMI.Execquery(“Select userName from Win32_computersystem”)
‘WMI ExecQueries returns a SWbemObjectSet collection data structure
‘even when there is only one item in the collection. For this reason
‘we use the For Each construct to list the userName property
For Each item In colItems ‘iterate through collection
WScript.Echo item.userName ‘display user name on screen
Next

Just for fun, I also created a very short version of this script:

WScript.Echo GetObject(“winmgmts:”).Execquery(“Select * from Win32_computersystem”).itemIndex(0).userName

If you want to know exactly what we will be looking at tomorrow, follow us on Twitter or Facebook. If you have any questions, send e-mail to us at scripter@microsoft.com or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson and Craig Liebendorfer, Scripting Guys

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

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

Get-Content -Path C:Filesservices.txt | Restart-Service

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

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

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

Обработка непрерывающих ошибок

Для получения ошибки возьмем службу с ″оригинальным″ названием Service. Поскольку службы этой на сервере нет, то обращение к ней стабильно будет генерировать ошибку. Запросим данные о нескольких службах командой:

Get-Service service,spooler

Как видно из примера, PowerShell не нашел службу Service, о чем выдал ошибку и затем продолжил выполнение команды. Давайте разберемся, почему команда повела себя именно так и как это поведение изменить.

За поведение команды при возникновении ошибки отвечает параметр ErrorAction, который может принимать одно из пяти значений:

• Continue;
• SilentlyContinue;
• Stop;
• Ignore;
• Inquire.

Примечание. Еще у ErrorAction может быть значение Suspend. Но это значение может применяться только к рабочим процессам (workflows), поэтому в рамках данной статьи речь о нем не пойдет.

Значение Continue означает, что при возникновении ошибки информация об этом будет выведена на экран (отправлена в поток вывода Error) и добавлена в автоматическую переменную $Error, после чего выполнение команды будет продолжено. Надо сказать, что Continue — это действие, определенное в сеансе по умолчанию, поэтому его можно не указывать явно.

При значении SilentlyContinue информация об ошибке добавляется в переменную $Error, но не выводится на экран. При этом команда продолжает выполняться дальше, также как и в предыдущем случае.

Значение Stop останавливает дальнейшее выполнение команды при возникновении ошибки. И наоборот, значение Ignore полностью игнорирует возникновение ошибки, при этом не выводится сообщение на экран и не производится запись в $Error. Это значение появилось в PowerShell 3.0.

Inquire — наиболее интересное значение ErrorAction. Если задать это значение, то при возникновении ошибки предлагается на выбор несколько действий: продолжить (Yes), продолжить не смотря на эту и все последующие ошибки (Yes to All), остановить (Halt) или приостановить (Suspend) выполнение команды.

Самый необычный эффект дает Suspend, при выборе которого открывается параллельный сеанс (Nested Namespace). Определить его можно по значку >>. Nested Namespace представляет из себя дочерний процесс, в котором можно полноценно работать — выполнять команды, запускать скрипты и т.п. Этот режим удобно использовать для отладки скриптов, например можно по быстрому исправить причину ошибки и продолжить выполнение. Для выхода из Nested Namespace достаточно набрать exit и выбрать необходимое действие.

Примечание. У параметра ErrorAction есть алиас — EA. Кроме того, вместо названия параметра можно указывать числовые значения: 0 (SilentlyContinue), 1 (Stop), 2 (Continue), 3 (Inquire). Так например, вместо:

Get-Service service,spooler -ErrorAction SilentlyContinue

можно написать так:

Get-Service service,spooler -EA 0

Переменные для обработки ошибок

Как я уже говорил, если не указывать параметр ErrorAction, то для команды действует режим обработки ошибок, определенный в сеансе. Этот режим задается переменной $ErrorActionPreference, которая по умолчанию имеет значение Continue. При желании можно переопределить режим для всего сеанса, задав переменной $ErrorActionPreference нужное значение.

Все ошибки PowerShell сохраняет в автоматическую переменную $Error. Это глобальная переменная, которая представляет из себя массив строк, содержащий записи обо всех ошибках в текущем сеансе. Каждая новая ошибка добавляется в начало массива, соответственно для просмотра последней ошибки надо обратиться к самому первому элементу массива $Error[0].

$Error имеет свои свойства и методы, которые можно использовать. Например, посмотреть общее количество ошибок в текущем сеансе можно командой $Error.Count, а очистить список — командой $Error.Clear().

Переменная $Error не безразмерна, по умолчанию она хранит не более 256 ошибок. При превышении этого количества наиболее старые ошибки будут затираться. При необходимости количество записей в переменной $Error можно увеличить, изменив значение другой переменной $MaximumErrorCount.

Кроме $Error для хранения ошибок допускается задавать собственные переменные. Сделать это можно с помощью параметра ErrorVariable, например так:

Get-Service service,spooler -ErrorAction SilentlyContinue -ErrorVariable var

Обратите внимание, что имя переменной в команде задается без знака $, хотя в дальнейшем к ней обращаемся как к обычной переменной $var.

В отличие от глобальной переменной $Error заданные вручную переменные хранят только ошибки той команды, в которой они определены. Кроме того, по умолчанию эти переменные каждый раз перезаписываются и поэтому хранят только последнюю ошибку. Если вы хотите, чтобы новые ошибки добавлялись в переменную, не перезаписывая ее содержимое, то перед именем переменной надо поставить знак +, например +var.

Пока все, а в следующей части пойдет о способах обработки прерывающих ошибок.

Время прочтения
5 мин

Просмотры 240K

Только автоматизация. Только PowerShell.

Предисловие

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

Я работаю системным администратором в крупной не ИТ-компании с большой завязкой на ИТ ресурсы. По роду деятельности представляется решать большое количество однотипных задач по обслуживанию пользователей.

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

Внимание: PowerShell вызывает привыкание.

Введение

Википедия говорит нам:

Windows PowerShell — расширяемое средство автоматизации от Microsoft, состоящее из оболочки с интерфейсом командной строки и сопутствующего языка сценариев.

Выглядеть среда PowerShell может так, как командная строка:

powershell.exe

Или в виде приложения:

powershell_ise.exe

Powershell_ise.exe называется интегрированной средой сценариев — Windows PowerShell ISE. Позволяет работать с языком в удобной среде с подсветкой синтаксиса, конструктором команд, автозаполнением команд по нажатию TAB и прочими прелестями. Идеальна для создания и тестирования сценариев.

Для запуска среды powershell.exe или powershell_ise.exe достаточно набрать аналогичное название в строке выполнить.

Файл сценария PowerShell имеет расширение .ps1.

Сценарий не получится запустить двойным ЛКМ. Это сделано специально для того, чтобы не нанести вред системе случайно запущенным скриптом.

Для запуска, по клику ПКМ следует выбрать «Выполнить с помощью PowerShell»:

Помимо того, что существует ограничение по запуску сценариев ЛКМ, по умолчанию выполнение сценариев в системе запрещено, опять же, по описанной выше причине — не нанести вред системе. Для проверки текущей политики выполнения выполним команду:

Get-ExecutionPolicy

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

• Restricted — Сценарии не могут быть запущены;
• AllSigned — Могут быть запущены только сценарии, подписанные доверенным издателем. Перед выполнением сценария доверенного издателя будет запрашиваться подтверждение;
• RemoteSigned — Разрешено выполнять созданные нами сценарии и скачанные сценарии, подписанные доверенным издателем;
• Unrestricted — Никаких ограничений, все скрипты могут быть запущены.

Для выполнения и тестирования понизим политику до RemoteSigned выполнив команду:

Set-ExecutionPolicy RemoteSigned

Приступаем к работе

Командлет

• Командлетами называются команды PowerShell, в которых заложена различная функциональность;
• Командлеты могут быть как системными, так и пользовательскими, созданные кем-либо;
• Командлеты именуются по правилу Глагол-Существительное, что упрощает их запоминание;
• Командлеты выводят результаты в виде объектов или их коллекций;
• Командлеты могут как получать данные для обработки, так и передавать данные по конвейеру (про конвейеры позже);
• Командлеты не чувствительны к регистру (можно написать и get-process, и Get-Process, и GeT-pRoCeSs);
• После командлетов не обязательно ставить «;«, за исключением, когда мы выполняем несколько командлетов в одну строку (Get-Process; Get-Services).

Например, для получения текущих процессов, мы выполним команду:

Get-Process 

И получим результат:

Попробуйте самостоятельно выполнить:

Get-Service #для получения статуса служб, запущенных на компьютерах

Get-Content C:WindowsSystem32driversetchosts #для получения содержимого файла. В данном случае, файл hosts

Не обязательно знать наизусть все командлеты. Get-Help спасёт ситуацию.
Информацию о всех доступных командлетах можно получить, введя следующую команду:

Get-Help -Category cmdlet

Если мы используем PowerShell ISE, мы облегчаем процесс разработки.
Достаточно ввести знак тире «—» после того, как ввели командлет, и мы получим все возможные варианты параметров и их типы:

Попробуйте выполнить:

Get-Service -Name p*

Если, всё же, мы забудем какие свойства есть у того или иного командлета, прогоним его через Get-Member:

Get-Process | Get-Member

#Знак "|" называется конвейером. О нём ниже.

Недостаточно информации? Обратимся к справке с параметром -Examples:

Get-Help Get-Process -Examples

Получаем описание Get-Process, да ещё и с примерами использования:

• Командлеты могут иметь сокращённые названия — алиасы. Например, вместо Get-Help можно использовать просто Help. Для получения всех сокращений выполните Get-Alias.

Попробуйте выполнить:

Start-Process notepad

Что аналогично записи:

start notepad

А теперь остановим процесс:

Stop-Process -Name notepad

Или так:

spps -Name notepad

Немногим ранее мы сказали, что командлеты именуются по правилу Глагол-Существительное. Уточню, что глагол не обязательно должен быть Get. Помимо того, что мы можем получать, мы можем задавать Set (помните, Set-ExecutionPolicy), запускать Start, останавливать Stop, выводить Out, создавать New и многие другие. Название командлета ни чем не ограничивается и, когда мы будем с вами создавать свой собственный, сможем назвать его так, как душе угодно.

Попробуем выполнить вывод в файл:

"Hello, Habr!" | Out-File C:test.txt
& C:test.txt

Кстати, аналогично можно записать так:

"Hello, Habr!" > C:test.txt
& C:test.txt

Комментарии

Мы все знаем, использовать комментарии является хорошим тоном.

Комментарии в PowerShell бывают строчные — # и блочные — <#… #>:

Обратим внимание, на код из примера:

Get-WmiObject -Class Win32_OperatingSystem | SELECT Caption

Для тех, кто знаком с WMI, кто делает это на старом добром VBScript, помните, сколько кода надо написать?

On Error Resume Next
strComputer = "."
Set objWMIService = GetObject("winmgmts:\" & strComputer & "rootcimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_OperatingSystem",,48)
For Each objItem in colItems
    Wscript.Echo "Caption: " & objItem.Caption
Next

Конвейер

Конвейер (|) — передаёт выходные данные одной команды во входные данные на обработку другой команде. Мы использовали конвейер ранее, получая все свойства объекта или, в предыдущем примере, выбирая из набора данных только поле Caption.

Чтобы понять принцип конвейера, давайте выполним код:

Get-Service | Sort-Object -property Status

Что произойдёт: получаем все службы (Get-Service), передаём все полученные службы на сортировку в командлет Sort-Object и указываем, что хотим отсортировать их по параметру Status. На выводе мы получим сначала все службы со статусом Stop, а потом все службы со статусом Running.

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

Get-Service | WHERE {$_.status -eq "Running"} | SELECT displayname

В примере мы используем $_. Данная запись означает текущий элемент в конвейере.

Послесловие

В этой части мы научились запускать PowerShell, разобрались с политикой выполнения сценариев. Поняли, что такое командлеты, знаем, как передавать их по конвейеру и как получить их свойства. Если мы что-то забудем, обязательно Get-Help.

Все это знания нужные для того, чтобы сделать первый прыжок в язык. Поверьте, ещё много интересного!

Продолжение следует…

Дополнительная информация

• Jump Start в PowerShell (часть II);
• Скачать PowerShell v.5 бесплатно без регистрации;
• Замечательный курс на MVA: Расширенные возможности и написание скриптов в PowerShell 3.0 (Jump Start). Мой совет — посмотрите первые 3 блока, окунитесь в язык, попробуйте повыполнять какие-нибудь задачи и через недельку смотрите оставшиеся блоки. Русские субтитры;
• Видео в тему на TechDays;
  Галерея скриптов PowerShell на Technet;
  Блог разработчиков PowerShell.

Example

Possible values are Continue | Ignore | Inquire | SilentlyContinue | Stop | Suspend.

Value of this parameter will determine how the cmdlet will handle non-terminating errors (those generated from Write-Error for example; to learn more about error handling see [topic not yet created]).

Default value (if this parameter is omitted) is Continue.

-ErrorAction Continue

This option will produce an error message and will continue with execution.

PS C:> Write-Error "test" -ErrorAction Continue ; Write-Host "Second command"

-ErrorAction Ignore

This option will not produce any error message and will continue with execution. Also no errors will be added to $Error automatic variable.
This option was introduced in v3.

PS C:> Write-Error "test" -ErrorAction Ignore ; Write-Host "Second command"

-ErrorAction Inquire

This option will produce an error message and will prompt user to choose an action to take.

PS C:> Write-Error "test" -ErrorAction Inquire ; Write-Host "Second command"

-ErrorAction SilentlyContinue

This option will not produce an error message and will continue with execution. All errors will be added to $Error automatic variable.

PS C:> Write-Error "test" -ErrorAction SilentlyContinue ; Write-Host "Second command"

-ErrorAction Stop

This option will produce an error message and will not continue with execution.

PS C:> Write-Error "test" -ErrorAction Stop ; Write-Host "Second command"

-ErrorAction Suspend

Only available in Powershell Workflows. When used, if the command runs into an error, the workflow is suspended. This allows investigation of such error and gives a possibility to resume the workflow. To learn more about Workflow system, see [topic not yet created].