All posts by Adam

about_functions_cmdletbindingattribute

TOPIC
    about_functions_CmdletBindingAttribute

SHORT DESCRIPTION
    Describes an attribute that declares a Function that acts similar to a
    compiled cmdlet.

LONG DESCRIPTION
    When you write Functions, you can add the CmdletBinding attribute so that
    Windows PowerShell will bind the parameters of the Function in the same
    way that it binds the parameters of compiled cmdlets. When this attribute
    is declared, Windows PowerShell also sets the $PSCmdlet automatic Variable.

    When you use cmdlet binding, unknown parameters and positional arguments
    that have no matching positional parameters cause parameter binding to
    fail. Also, a Function or script with cmdlet binding does not use the
    $args Variable.

    Note: Compiled cmdlets use the required Cmdlet attribute, which is similar
         to the CmdletBinding attribute that is described in this topic.

    The following example shows the outline of a Function that specifies all
    the optional arguments of the CmdletBinding attribute. A brief description
    of each argument follows this example.

        {
         [CmdletBinding(SupportsShouldProcess=<Boolean>,
                     ConfirmImpact=<String>,
                     DefaultParameterSetName=<String>)]

         Param ($Parameter1)
         Begin{}
         Process{}
         End{}
        }

SupportsShouldProcess

     When the SupportsShouldProcess argument is set to true, it indicates that
     the Function supports calls to the ShouldProcess method, which is used to
     prompt the user for feedback before the Function makes a change to the
     system. When this argument is specified, the Confirm and WhatIf
     parameters are enabled for the Function.

     For more information about confirmation requests, see “Requesting
     Confirmation” in the MSDN (Microsoft Developer Network) library at
     http://go.microsoft.com/fwlink/?LinkId=136658.

DefaultParameterSetName

     The DefaultParameterSetName argument specifies the name of the parameter
     set that Windows PowerShell will attempt to use when it cannot determine
     which parameter set to use. You can avoid this issue by making the
     unique parameter of each parameter set a mandatory parameter.

ConfirmImpact

     The ConfirmImpact argument specifies when the action of the Function
     should be confirmed by a call to the ShouldProcess method. The call to
     the ShouldProcess method displays a confirmation prompt only when the
     ConfirmImpact argument is equal to or greater than the value of the
     $ConfirmPreference preference Variable. (The default value of the
     argument is Medium.) Specify this argument only when the
     SupportsShouldProcess argument is also specified.

SEE ALSO
    about_functions_advanced
    about_functions_CmdletBindingAttribute
    about_functions_ParameterAttributes

about_functions_advanced_parameters

TOPIC
    about_functions_advanced_parameters

SHORT DESCRIPTION
    Explains how to add static and dynamic parameters to Functions that declare
    the CmdletBinding attribute.

LONG DESCRIPTION
    You can declare your own parameters when you write Functions, and you can
    write Functions so that they can access the common parameters that are
    available to compiled cmdlets. For more information about the
    Windows PowerShell common parameters, see about_CommonParameters.

Static Parameters

    The following example shows a parameter declaration that defines a
    ComputerName parameter. This parameter has the following characteristics:

        – It is required.
        – It takes input from the pipeline.
        – It takes an array of strings as input.

        Param
         (
            [parameter(Mandatory=$true,
            ValueFromPipeline=$true)]
            [String[]]
            $ComputerName
         )

    The only required attribute that must be used when you declare a parameter
    is the Parameter attribute. However, you can also declare the Alias
    attribute and several validation arguments. There are no limits to the
    number of attributes that you can add to a parameter declaration.

Parameter Attribute

     The Parameter attribute is used to declare a parameter of the Function.
     This attribute has the following named arguments that are used to define
     the characteristics of the parameter, such as whether the parameter is
     required or optional.

    Mandatory Named Argument

        The Mandatory argument indicates that the parameter is required when
        the Function is run. If this argument is not specified, the parameter
        is an optional parameter. The following example shows the declaration
        of a parameter that is required when the Function is run.

        Param
         (
            [parameter(Mandatory=$true)]
            [String[]]
            $ComputerName
         )

    Position Named Argument

        The Position argument specifies the position of the parameter. If this
        argument is not specified, the parameter name or its Alias must be
        explicitly specified when the parameter is set. Also, if none of the
        parameters of a Function have positions, the Windows PowerShell runtime
        assigns positions to each parameter based on the order in which the
        parameters are received.

        The following example shows the declaration of a parameter whose value
        must be specified as the first argument when the cmdlet is run. Notice
        that this Function could be run with or without specifying the name of
        the parameter.

        Param
         (
            [parameter(Position=0)]
            [String[]]
            $ComputerName
         )

    ParameterSetName Named Argument

        The ParameterSetName argument specifies the parameter set to which a
        parameter belongs. If no parameter set is specified, the parameter
        belongs to all the parameter sets defined by the Function. This
        behavior means that each parameter set must have one unique parameter
        that is not a member of any other parameter set. The following example
        shows the parameter declaration of two parameters that belong to two
        different parameter sets.

        Param
         (
            [parameter(Mandatory=$true,
                     ParameterSetName=”Computer”)]
            [String[]]
            $ComputerName
         )

        Param
         (
            [parameter(Mandatory=$true,
                     ParameterSetName=”User”)]
            [String[]]
            $UserName
         )

        For more information about parameter sets, see “Cmdlet Parameter Sets”
        in the MSDN library at http://go.microsoft.com/fwlink/?LinkId=142183.

    ValueFromPipeline Named Argument

        The ValueFromPipeline argument specifies that the parameter accepts
        input from a pipeline object. Specify this argument if the cmdlet
        accesses the complete object, not just a property of the object. The
        following example shows the parameter declaration of a mandatory
        ComputerName parameter that accepts the input object that is passed
        to the Function from the pipeline.

        Param
         (
            [parameter(Mandatory=$true,
                     ValueFromPipeline=$true)]
            [String[]]
            $ComputerName
         )

    ValueFromPipelineByPropertyName Named Argument

        The valueFromPipelineByPropertyName argument specifies that the
        parameter accepts input from a property of a pipeline object. Specify
        this attribute if the following conditions are true:

            – The parameter accesses a property of the piped object.

            – The property has the same name as the parameter, or the property
             has the same Alias as the parameter.

        For example, if the Function has a ComputerName parameter, and the
        piped object has a ComputerName property, the value of the ComputerName
        property is assigned to the ComputerName parameter of the Function.

        The following example shows the parameter declaration of a ComputerName
        parameter that accepts input from the ComputerName property of the
        input object that is passed to the cmdlet.

        Param
         (
            [parameter(Mandatory=$true,
                     ValueFromPipelineByPropertyName=$true)]
            [String[]]
            $ComputerName
         )

    ValueFromRemainingArguments Named Argument

        The ValueFromRemainingArguments argument specifies that the parameter
        accepts all of the remaining arguments that are not bound to the
        parameters of the Function. The following example shows the parameter
        declaration of a ComputerName parameter that accepts all the remaining
        arguments of the input object that is passed to the Function.

        Param
         (
            [parameter(Mandatory=$true,
                     ValueFromRemainingArguments=$true)]
            [String[]]
            $ComputerName
         )

    HelpMessage Named Argument

        The HelpMessage argument specifies a message that contains a short
        description of the parameter. The following example shows a parameter
        declaration that provides a description of the parameter.

        Param
         (
            [parameter(Mandatory=$true,
                     HelpMessage=”An array of computer names.”)]
            [String[]]
            $ComputerName
         )

Alias Attribute

     The Alias attribute specifies another name for the parameter. There is
     no limit to the number of Aliases that can be assigned to a parameter.
     The following example shows a mandatory parameter declaration that adds
     the “CN” Alias to the ComputerName parameter.

        Param
         (
            [parameter(Mandatory=$true)]
            [alias(“CN”)]
            [String[]]
            $ComputerName
         )

Parameter Validation Attributes

     These attributes define how the Windows PowerShell runtime validates the
     arguments of advanced Functions.

    AllowNull Validation Attribute

        The AllowNull attribute allows the argument of a mandatory cmdlet
        parameter to be set to Null. In the following example, the ComputerName
        parameter can contain a value of Null even though this parameter is a
        mandatory parameter.

        Param
         (
            [parameter(Mandatory=$true)]
            [String]
            [AllowNull()]
            $ComputerName
         )

    AllowEmptyString Validation Attribute

        The AllowEmptyString attribute allows an empty string as the argument
        of a mandatory cmdlet parameter. In the following example, the
        ComputerName parameter can contain an empty string (“”) even though
        this parameter is a mandatory parameter.

        Param
         (
            [parameter(Mandatory=$true)]
            [String]
            [AllowEmptyString()]
            $ComputerName
         )

    AllowEmptyCollection Validation Attribute

        The AllowEmptyCollection attribute allows an empty collection as the
        argument of a mandatory parameter.

        Param
         (
            [parameter(Mandatory=$true)]
            [String[]]
            [AllowEmptyCollection()]
            $ComputerName
         )

    ValidateCount Validation Attribute

        The ValidateCount attribute specifies the minimum and maximum number
        of arguments that the parameter can accept. The Windows PowerShell
        runtime generates an error if the number of arguments is outside that
        range. In the following example, the ComputerName parameter can have
        one to five arguments.

        Param
         (
            [parameter(Mandatory=$true)]
            [String[]]
            [ValidateCount(1,5)]
            $ComputerName
         )

    ValidateLength Validation Attribute

        The ValidateLength attribute specifies the minimum and maximum length
        of the parameter argument. The Windows PowerShell runtime generates an
        error if the length of the parameter argument is outside that range.
        In the following example, the specified computer names must have one
        to 10 characters.

        Param
         (
            [parameter(Mandatory=$true)]
            [String[]]
            [ValidateLength(1,10)]
            $ComputerName
         )

    ValidatePattern Validation Attribute

        The ValidatePattern attribute specifies a regular expression that
        validates the pattern of the parameter argument. The Windows PowerShell
        runtime generates an error if the parameter argument does not match
        this pattern. In the following example, the argument of the parameter
        must be a four-digit number, and each digit must be a number 0 to 9.

        Param
         (
            [parameter(Mandatory=$true)]
            [String[]]
            [ValidatePattern(“[0-9][0-9][0-9][0-9]”)]
            $ComputerName
         )

    ValidateRange Validation Attribute

        The ValidateRange attribute specifies the minimum and maximum values
        of the parameter argument. The Windows PowerShell runtime generates
        an error if the parameter argument is outside that range. In the
        following example, the argument of the parameter cannot be less than
        0 or greater than 10.

        Param
         (
            [parameter(Mandatory=$true)]
            [Int[]]
            [ValidateRange(0,10)]
            $Count
         )

    ValidateScript Validation Attribute

        The ValidateScript attribute specifies a script that is used to
        validate the parameter argument. The Windows PowerShell runtime
        generates an error if the script result is false or if the script
        throws an exception. In the following example the value of the Count
        parameter must be less than 4.

        Param
         (
            [parameter()]
            [Int]
            [ValidateScript({$_ -lt 4})]
            $Count
         )

    ValidateSet Attribute

        The ValidateSet attribute secifies a set of valid values for the
        argument of the parameter. The Windows PowerShell runtime generates
        an error if the parameter argument does not match a value in the set.
        In the following example, the argument of the parameter can contain
        only the names Steve, Mary, and Carl.

        Param
         (
            [parameter(Mandatory=$true)]
            [String[]]
            [ValidateRange(“Steve”, “Mary”, “Carl”)]
            $UserName
         )

    ValidateNotNull Validation Attribute

        The ValidateNotNull attribute specifies that the argument of the
        parameter cannot be set to Null. The Windows PowerShell runtime
        generates an error if the parameter value is Null.

        Param
         (
            [parameter(Mandatory=$true)]
            [String[]]
            [ValidateNotNull()]
            $UserName
         )

    ValidateNotNullOrEmpty Validation Attribute

        The ValidateNotNullOrEmpty attribute specifies that the argument of
        the parameter cannot be set to Null or it cannot be empty. The Windows
        PowerShell runtime generates an error if the parameter is specified
        but its value is Null, an empty string, or an empty array.

        Param
         (
            [parameter(Mandatory=$true)]
            [String[]]
            [ValidateNotNullOrEmpty()]
            $UserName
         )

Dynamic Parameters

    Dynamic parameters are parameters of a cmdlet, Function, or script
    that are available only under certain conditions.

    For example, several provider cmdlets have parameters that are
    available only when the cmdlet is used in the provider path.
    One familiar dynamic parameter is the Encoding parameter of the
    Set-Item, cmdlet, which is available only when the Set-Item cmdlet
    is used in a FileSystem provider path.

    To create a dynamic parameter for a Function or script, use the
    DynamicParam keyword.

    The syntax is as follows.

     DynamicParam {<statement-list>}

    In the statement list, use an If statement to specify the
    conditions under which the parameter is available in the Function.

    Use the New-Object cmdlet to create a
    System.Management.Automation.RuntimeDefinedParameter object to
    represent the parameter and specify its name.

    You can also use a New-Object command to create a
    System.Management.Automation.ParameterAttribute object to represent
    attributes of the parameter, such as Mandatory, Position, or
    ValueFromPipeline or its parameter set.

    The following example shows a sample Function with standard
    parameters called Name and Path, and an optional dynamic parameter
    named DP1. The DP1 parameter is in the PSet1 parameter set and has
    a type of Int32. The DP1 parameter is available in the Sample
    Function only when the value of the Path parameter contains “HKLM:”,
    indicating that it is being used in the HKEY_LOCAL_MACHINE Registry
    drive.

    Function Sample {
     Param ([String]$Name, [String]$Path)

     DynamicParam
     {
        if ($path -match “*HKLM*:”)
        {
         $dynParam1 = New-Object
            System.Management.Automation.RuntimeDefinedParameter(“dp1”,
            [Int32], $attributeCollection)

         $attributes = New-Object System.Management.Automation.ParameterAttribute
         $attributes.ParameterSetName = ‘pset1’
         $attributes.Mandatory = $false

         $attributeCollection = New-Object
            -Type System.Collections.ObjectModel.Collection“1[System.Attribute]
         $attributeCollection.Add($attributes)

         $paramDictionary = New-Object
            System.Management.Automation.RuntimeDefinedParameterDictionary
         $paramDictionary.Add(“dp1”, $dynParam1)

         return $paramDictionary
        } End if
     }
    }

    For more information, see “RuntimeDefinedParameter Class” in
    the MSDN (Microsoft Developer Network) library at
    http://go.microsoft.com/fwlink/?LinkID=145130.

SEE ALSO
    about_Advanced Functions
    about_functions_advanced_methods
    about_functions_CmdletBindingAttribute

about_functions_advanced_methods

TOPIC
    about_functions_advanced_methods

SHORT DESCRIPTION
    Describes how Functions that specify the CmdletBinding attribute can use
    the methods and properties that are available to compiled cmdlets.

LONG DESCRIPTION
    Functions that specify the CmdletBinding attribute can access a number of
    methods and properties through the $pscmdlet Variable. These methods
    include the following methods:

        – Input-processing methods that compiled cmdlets use to do their work.

        – The ShouldProcess and ShouldContinue methods that are used to get
         user feedback before an action is performed.

        – The ThrowTerminatingError method for generating error records.

        – Several Write methods that return different types of output.

        – Several Write methods that return different types of output.

    All the methods and properties of the PSCmdlet class are available to
    advanced Functions. For more information about these methods and
    properties, see System.Management.Automation.PSCmdlet in the MSDN
    (Microsoft Developer Network) library at
    http://go.microsoft.com/fwlink/?LinkId=142139.

Input Processing Methods

     The methods described in this section are referred to as the input
     processing methods. For Functions, these three methods are represented
     by the Begin, Process, and End blocks of the Function. Each Function
     must include one or more of these blocks. The Windows PowerShell runtime
     uses the code within these blocks when it is running a Function. (These
     blocks are also available to Functions that do not use the CmdletBinding
     attribute.)

    Begin
     This block is used to provide optional one-time preprocessing for the
     Function. The Windows PowerShell runtime uses the code in this block one
     time for each instance of the Function in the pipeline.

    Process
     This block is used to provide record-by-record processing for the
     Function. This block might be used any number of times, or not at all,
     depending on the input to the Function. For example, if the Function is
     the first command in the pipeline, the Process block will be used one
     time. If the Function is not the first command in the pipeline, the
     Process block is used one time for every input that the Function
     receives from the pipeline. If there is no pipeline input, the Process
     block is not used.

     This block must be defined if a Function parameter is set to accept
     pipeline input. If this block is not defined and the parameter accepts
     input from the pipeline, the Function will miss the values that are
     passed to the Function through the pipeline.

     Also, when the Function supports confirmation requests (when the
     SupportsShouldProcess parameter of the Parameter attribute is set to
     $True), the call to the ShouldProcess method must be made from within
     the Process block.

    End
     This block is used to provide optional one-time post-processing for
     the Function.

     The following example shows the outline of a Function that contains a
     Begin block for one-time preprocessing, a Process block for multiple
     record processing, and an End block for one-time post-processing.

         Function Test-ScriptCmdlet
         {
            [CmdletBinding(SupportsShouldProcess=$True)]
            Param ($Parameter1)
            Begin{}
            Process{}
            End{}
         }

Confirmation Methods

    ShouldProcess
     This method is called to request confirmation from the user before the
     Function performs an action that would change the system. The Function
     can continue based on the Boolean value returned by the method. This
     method can be called only from within the Process{} block of the
     Function. And, the CmdletBinding attribute must declare that the
     Function supports ShouldProcess (as shown in the previous example).

     For more information about this method, see
     System.Management.Automation.Cmdlet.ShouldProcess in the MSDN library at
     http://go.microsoft.com/fwlink/?LinkId=142142.

     For more information about how to request confirmation, see
     “Requesting Confirmation” in the MSDN library at
     http://go.microsoft.com/fwlink/?LinkID=136658.

    ShouldContinue
     This method is called to request a second confirmation message. It
     should be called when the ShouldProcess method returns $true. For more
     information about this method, see
     System.Management.Automation.Cmdlet.ShouldContinue in the MSDN library
     at http://go.microsoft.com/fwlink/?LinkId=142143.

Error Methods

    Functions can call two different methods when errors occur. When a
    nonterminating error occurs, the Function should call the WriteError
    method, which is described in the “Write Methods” section. When a
    terminating error occurs and the Function cannot continue, it should call
    the ThrowTerminatingError method. You can also use the Throw statement for
    terminating errors and the Write-Error cmdlet for nonterminating errors.

    For more information, see System.Management.Automation.Cmdlet.
    ThrowTerminatingError in the MSDN libray at
    http://go.microsoft.com/fwlink/?LinkId=142144.

Write Methods

     A Function can call the following methods to return different types of
     output. Notice that not all the output goes to the next command in the
     pipeline. You can also use the various Write cmdlets, such as
     Write-Error.

    WriteCommandDetail
     For information about the WriteCommandDetails method, see
     System.Management.Automation.Cmdlet.WriteCommandDetail in the MSDN
     library at http://go.microsoft.com/fwlink/?LinkId=142155.

    WriteDebug
     To provide information that can be used to troubleshoot a Function,
     make the Function call the WriteDebug method. This displays debug
     messages to the user. For more information, see
     System.Management.Automation.Cmdlet.WriteDebug in the MSDN library
     at http://go.microsoft.com/fwlink/?LinkId=142156.

    WriteError
     Functions should call this method when nonterminating errors occur and
     the Function is designed to continue processing records. For more
     information, see System.Management.Automation.Cmdlet.WriteError in the
     MSDN library at http://go.microsoft.com/fwlink/?LinkId=142157.

     Note: If a terminating error occurs, the Function should call the
            ThrowTerminatingError method.

    WriteObject
     This method allows the Function to send an object to the next command in
     the pipeline. In most cases, this is the method to use when the Function
     returns data. For more information, see
     System.Management.Automation.PSCmdlet.WriteObject in the MSDN library at
     http://go.microsoft.com/fwlink/?LinkId=142158.

    WriteProgress
     For Functions whose actions take a long time to complete, this method
     allows the Function to call the WriteProgress method so that progress
     information is displayed. For example, you can display the percent
     completed. For more information, see
     System.Management.Automation.PSCmdlet.WriteProgress in the MSDN library
     at http://go.microsoft.com/fwlink/?LinkId=142160.

    WriteVerbose
     To provide detailed information about what the Function is doing, make
     the Function call the WriteVerbose method to display verbose messages to
     the user. By default, verbose messages are not displayed. For more
     information, see System.Management.Automation.PSCmdlet.WriteVerbose
     in the MSDN library at http://go.microsoft.com/fwlink/?LinkId=142162.

    WriteWarning
     To provide information about conditions that may cause unexpected
     results, make the Function call the WriteWarning method to display
     warning messages to the user. By default, warning messages are displayed.
     For more information, see
     System.Management.Automation.PSCmdlet.WriteWarning in the MSDN library
     at http://go.microsoft.com/fwlink/?LinkId=142164.

     Note: You can also display warning messages by configuring the
            WarningPreference Variable or by using the Verbose and Debug
            command-line options.

Other Methods and Properties

     For information about the other methods and properties that can be
     accessed through the $PSCmdlet Variable, see
     System.Management.Automation.PSCmdlet in the MSDN library at
     http://go.microsoft.com/fwlink/?LinkId=142139.

     For example, the ParameterSetName property allows you to see the parameter
     set that is being used. Parameter sets allow you to create a Function that
     performs different tasks based on the parameters that are specified when
     the Function is run.

SEE ALSO
    about_functions_advanced
    about_functions_CmdletBindingAttributes
    about_functions_advanced_parameters

about_functions_advanced

TOPIC
    about_functions_advanced

SHORT DESCRIPTION
    Introduces advanced Functions that act similar to cmdlets.

LONG DESCRIPTION
    Advanced Functions allow you to write Functions that can perform operations
    that are similar to the operations you can perform with cmdlets. Advanced
    Functions are helpful when you want to quickly write a Function without
    having to write a compiled cmdlet using a Microsoft .NET Framework
    language. These Functions are also helpful when you want to restrict the
    Functionality of a compiled cmdlet or when you want to write a Function
    that is similar to a compiled cmdlet.

    There is a difference between authoring a compiled cmdlet and an advanced
    Function. Compiled cmdlets are .NET Framework classes that must be written
    in a .NET Framework language such as C#. In contrast, advanced Functions
    are written in the Windows PowerShell script language in the same way that
    other Functions or script blocks are written.

    Advanced Functions use the CmdletBinding attribute to identify them as
    Functions that act similar to cmdlets. The CmdletBinding attribute is
    similar to the Cmdlet attribute that is used in compiled cmdlet classes to
    identify the class as a cmdlet. For more information about this attribute,
    see about_functions_CmdletBindingAttribute.

    The following example shows a Function that accepts a name and then prints
    a greeting using the supplied name. Also notice that this Function defines
    a name that includes a verb (Send) and noun (Greeting) pair similar to the
    verb-noun pair of a compiled cmdlet. However, Functions are not required
    to have a verb-noun name.

        Function Send-Greeting
        {
         [CmdletBinding()]
         Param(
             [Parameter(Mandatory=$true)]
             [string] $Name
         )
         Process
         {
            Write-Host (“Hello ” + $Name + “!”)
         }
        }

    The parameters of the Function are declared by using the Parameter
    attribute. This attribute can be used alone, or it can be combined with
    the Alias attribute or with several other parameter validation attributes.
    For more information about how to declare parameters (including dynamic
    parameters that are added at runtime), see
    about_functions_advanced_parameters.

    The actual work of the previous Function is performed in the Process
    block, which is equivalent to the ProcessingRecord method that is used by
    compiled cmdlets to process the data that is passed to the cmdlet. This
    block, along with the Begin and End blocks, is described in the
    about_functions_advanced_methods topic.

    Advanced Functions differ from compiled cmdlets in the following ways:

        – Advanced Function parameter binding does not throw an exception when
         an array of strings is bound to a Boolean parameter.

        – The ValidateSet attribute and the ValidatePattern attribute cannot
         pass named parameters.

        – Advanced Functions cannot be used in transactions.

SEE ALSO
    about_functions_advanced_CmdletBindingAttribute
    about_functions_advanced_methods
    about_functions_advanced_parameters
    Windows PowerShell Cmdlets (http://go.microsoft.com/fwlink/?LinkID=135279)

about_functions

TOPIC
    about_functions

SHORT DESCRIPTION
    Describes how to create and use Functions in Windows PowerShell.

LONG DESCRIPTION
    A Function is a list of statements that has a name that you assign. When
    you run a Function, you type the Function name. The statements in the list
    run as if you had typed them at the command prompt.

    Like cmdlets, Functions can have parameters. The parameters can be named,
    positional, switch, or dynamic parameters. Function parameters can be read
    from the command line or from the pipeline.

    Functions can return values that can be displayed, assigned to Variables,
    or passed to other Functions or cmdlets.

    The Function‘s statement list can contain different types of statement
    lists with the keywords Begin, Process, and End. These statement lists
    handle input from the pipeline differently.

    A filter is a special kind of Function that uses the Filter keyword.

    Functions can also act like cmdlets. You can create a Function that works
    just like a cmdlet without using C# programming. For more information,
    see about_functions_advanced.

Syntax
     The following is the syntax for a Function:

         Function [<scope:>]<name> [([type]$parameter1[,[type]$parameter2])]
         {
             param([type]$parameter1 [,[type]$parameter2])

             dynamicparam {<statement list>}

             begin {<statement list>}
             process {<statement list>}
             end {<statement list>}
         }

     A Function includes the following items:

         – A Function keyword
         – A scope (optional)
         – A name that you select
         – Any number of named parameters (optional)
         – One or more Windows PowerShell commands enclosed in braces ({})

     For more information about the Dynamicparam keyword and dynamic
     parameters in Functions, see about_functions_advanced_parameters.

Simple Functions
     Functions do not have to be complicated to be useful. The following
     Function gets the Environment Variables that do not belong to the System
     account of the current system:

         Function other_env
         {
             Get-WmiObject win32_environment |
                where {$_.username -ne “<System>”}
         }

     To run the Function, type “other_env”.

     You can create a toolbox of useful small Functions. Add these Functions
     to your Windows PowerShell profile, as described in about_profiles and
     later in this topic.

Functions with Parameters
     You can use parameters with Functions, including named parameters,
     positional parameters, switch parameters, and dynamic parameters. For
     more information about dynamic parameters in Functions,
     see about_functions_advanced_parameters.

Named Parameters
     You can define any number of named parameters. You can include a default
     value for named parameters, as described later in this topic.

     You can define parameters inside the braces using the Param keyword, as
     shown in the following sample syntax:

         Function <name> {
             param ([type]$parameter1[,[type]$parameter2])
             <statement list>
         }

     You can also define parameters outside the braces without the Param
     keyword, as shown in the following sample syntax:

         Function <name> [([type]$parameter1[,[type]$parameter2])] {
             <statement list>
         }

     There is no difference between these two methods. Use the method that
     you prefer.

     When you run the Function, the value you supply for a parameter is
     assigned to a Variable that contains the parameter name. The value of
     that Variable can be used in the Function.

     The following example is a Function called Small_files. This Function
     has a $size parameter. The Function displays all the files that are
     smaller than the value of the $size parameter, and it excludes
     directories:

         Function small_files {
             param ($size)
             Get-ChildItem c:\ | where {
                 $_.length -lt $size -and !$_.PSIsContainer}
         }

     In the Function, you can use the $size Variable, which is the name
     defined for the parameter.

     To use this Function, type the following command:

         C:\PS> Function small_files –size 50

     You can also enter a value for a named parameter without the parameter
     name. For example, the following command gives the same result as a
     command that names the Size parameter:

         C:\PS> Function small_files 50

     To define a default value for a parameter, type an equal sign and the
     value after the parameter name, as shown in the following variation of
     the Small_files example:

         Function small_files ($size = 100) {
             Get-ChildItem c:\ | where {
                 $_.length -lt $size -and !$_.PSIsContainer}
         }

     If you type “small_files” without a value, the Function assigns 100 to
     $size. If you provide a value, the Function uses that value.

Positional Parameters
     A positional parameter is a parameter without a parameter name. Windows
     PowerShell uses the parameter value order to associate each parameter
     value with a parameter in the Function.

     When you use positional parameters, type one or more values after the
     Function name. Positional parameter values are assigned to the $args
     array Variable. The value that follows the Function name is assigned to
     the first position in the $args array, $args[0].

     The following Extension Function adds the .txt file name extension to a
     file name that you supply:

         Function extension {
             $name = $args[0] + “.txt”
             $name
         }

         C:\PS> extension myTextFile
         myTextFile.txt

     Functions can take more than one positional parameter. The following
     example displays any values entered with the Function name.

         Function repeat { foreach ($arg in $args) { “The input is $arg” } }

         C:\PS>repeat one
         The input is one

         C:\PS> repeat one two three
         The input is one
         The input is two
         The input is three

     This Function can be used with any number of values. The Function
     assigns each value to a position in the $args array.

Switch Parameters
     A switch is a parameter that does not require a value. Instead, you type
     the Function name followed by the name of the switch parameter.

     To define a switch parameter, specify the type [switch] before the
     parameter name, as shown in the following example:

         Function switchExample {
             param ([switch]$on)
             if ($on) { “Switch on” }
             else { “Switch off” }
         }

     When you type the On switch parameter after the Function name, the
     Function displays “Switch on”. Without the switch parameter, it displays
     “Switch off”.

         C:\PS> SwitchExample -on
         Switch on

         C:\PS> SwitchExample
         Switch off

     You can also assign a Boolean value to a switch when you run the
     Function, as shown in the following example:

         C:\PS> SwitchExample -on:$true
         Switch on

         C:\PS> SwitchExample -on:$false
         Switch off

Piping Objects to Functions
     Any Function can take input from the pipeline. You can control how a
     Function processes input from the pipeline using Begin, Process, and End
     keywords. The following sample syntax shows the three keywords:

         Function <name> {
             begin {<statement list>}
             process {<statement list>}
             end {<statement list>}
         }

     The Begin statement list runs one time only, at the beginning of
     the Function.

     The Process statement list runs one time for each object in the pipeline.
     While the Process block is running, each pipeline object is assigned to
     the $_ automatic Variable, one pipeline object at a time.

     After the Function receives all the objects in the pipeline, the End
     statement list runs one time. If no Begin, Process, or End keywords are
     used, all the statements are treated like an End statement list.

     The following Function uses the Process keyword. The Function displays
     examples from the pipeline:

         Function pipelineFunction
         {
             process {“The value is: $_”}
         }

     To demonstrate this Function, enter an array of numbers created with
     commas, as shown in the following example:

         C:\PS> 1,2,4 | pipelineFunction
         The value is: 1
         The value is: 2
         The value is: 4

     When you use a Function in a pipeline, the objects piped to the Function
     are assigned to the $input automatic Variable. The Function runs
     statements with the Begin keyword before any objects come from the
     pipeline. The Function runs statements with the End keyword after all
     the objects have been received from the pipeline.

     The following example shows the $input automatic Variable with Begin and
     End keywords.

         Function PipelineBeginEnd
         {
             begin {“Begin: The input is $input”}
             end {“End: The input is $input” }
         }

     If this Function is run by using the pipeline, it displays the following
     results:

         C:\PS> 1,2,4 | PipelineBeginEnd
         Begin: The input is
         End: The input is 1 2 4

     When the Begin statement runs, the Function does not have the input from
     the pipeline. The End statement runs after the Function has the values.

     If the Function has a Process keyword, the Function reads the data in
     $input. The following example has a Process statement list:

         Function PipelineInput
         {
             process {“Processing: $_ ” }
             end {“End: The input is: $input” }
         }

     In this example, each object that is piped to the Function is sent to the
     Process statement list. The Process statements run on each object, one
     object at a time. The $input automatic Variable is empty when the
     Function reaches the End keyword.

         C:\PS> 1,2,4 | PipelineInput
         Processing: 1
         Processing: 2
         Processing: 4
         End: The input is:

Filters
     A filter is a type of Function that runs on each object in the pipeline.
     A filter resembles a Function with all its statements in a Process block.

     The syntax of a filter is as follows:

         filter [<scope:>]<name> {<statement list>}

     The following filter takes log entries from the pipeline and then
     displays either the whole entry or only the message portion of the entry:

         filter ErrorLog ([switch]$message)
         {
             if ($message) { Out-Host -inputobject $_.Message }
             else { $_ }
         }

Function Scope
     A Function exists in the scope in which it was created.

     If a Function is part of a script, the Function is available to
     statements within that script. By default, a Function in a script is not
     available at the command prompt.

     You can specify the scope of a Function. For example, the Function is
     added to the global scope in the following example:

         Function global:get-dependentsvs { Get-Service |
             where {$_.dependentservices} }

     When a Function is in the global scope, you can use the Function in
     scripts, in Functions, and at the command line.

     Functions normally create a scope. The items created in a Function, such
     as Variables, exist only in the Function scope.

     For more information about scope in Windows PowerShell, see about_Scopes/”>about_Scope.

Finding and Managing Functions Using the Function: Drive
     All the Functions and filters in Windows PowerShell are automatically
     stored in the Function: drive. This drive is exposed by the Windows
     PowerShell Function provider.

     When referring to the Function: drive, type a colon after Function, just
     as you would do when referencing the C or D drive of a computer.

     The following command displays all the Functions in the current session
     of Windows PowerShell:

         C:\PS>    dir Function:

     The commands in the Function are stored as a script block in the
     definition property of the Function. For example, to display the
     commands in the Help Function that comes with Windows PowerShell, type:

         (dir Function:help).definition

     For more information about the Function: drive, see Function.

Reusing Functions in New Sessions
     When you type a Function at the Windows PowerShell command prompt, the
     Function becomes part of the current session. It is available until the
     session ends.

     To use your Function in all Windows PowerShell sessions, add the Function
     to your Windows PowerShell profile. For more information about profiles,
     see about_profiles.

     You can also save your Function in a Windows PowerShell script file.
     Type your Function in a text file, and then save the file with the .ps1
     file name extension.

Writing Help for Functions
    The Get-Help cmdlet gets help for Functions, as well as for cmdlets,
    providers, and scripts. To get help for a Function, type Get-Help followed
    by the Function name.

    For example, to get help for the MyDisks Function, type:

        Get-Help MyDisks

    You can write help for a Function by using either of the two following methods:

    — Comment-Based Help for Functions

        Create a help topic by using special keywords in the comments. To create
        comment-based help for a Function, the comments must be placed at the
        beginning or end of the Function body or on the lines preceding the Function
        keyword. For more information about comment-based help, see
        about_Comment_Based_Help.

    — XML-Based Help for Functions

        Create an XML-based help topic, such as the type that is typically
        created for cmdlets. XML-based help is required if you are localizing
        help topics into multiple languages.

        To associate the Function with the XML-based help topic, use the
        .ExternalHelp help comment keyword. For more information about the
        ExternalHelp keyword, see about_Comment_Based_Help. For more information
        about XML-based help, see “How to Write Cmdlet Help” in MSDN.

SEE ALSO
    about_Automatic_Variables
    about_Comment_Based_Help
    about_functions_advanced
    about_functions_CmdletBindingAttribute
    about_parameters
    about_profiles
    about_scopes
    about_script_blocks
    Function (provider)

about_format.ps1xml

TOPIC
    about_Format.ps1xml

SHORT DESCRIPTION
    The Format.ps1xml files in Windows PowerShell define the default display
    of objects in the Windows PowerShell console. You can create your own
    Format.ps1xml files to change the display of objects or to define default
    displays for new object types that you create in Windows PowerShell.

LONG DESCRIPTION
    The Format.ps1xml files in Windows PowerShell define the default display
    of objects in Windows PowerShell. You can create your own Format.ps1xml
    files to change the display of objects or to define default displays
    for new object types that you create in Windows PowerShell.

    When Windows PowerShell displays an object, it uses the data in structured
    formatting files to determine the default display of the object. The
    data in the formatting files determines whether the object is rendered in
    a table or in a list, and it determines which properties are displayed by
    default.

    The formatting affects the display only. It does not affect which object
    properties are passed down the pipeline or how they are passed.

    Windows PowerShell includes seven formatting files. These files are
    located in the installation directory ($pshome). Each file defines the
    display of a group of Microsoft .NET Framework objects:

    Certificate.Format.ps1xml
            Objects in the Certificate store, such as X.509 Certificates and
            Certificate stores.

    DotNetTypes.Format.ps1xml
            Other .NET Framework types, such as CultureInfo, FileVersionInfo,
            and EventLogEntry objects.

    FileSystem.Format.ps1xml
            File system objects, such as files and directories.

    Help.Format.ps1xml
            Help views, such as detailed and full views, parameters, and
            examples.

    PowerShellCore.format.ps1xml
            Objects generated by Windows PowerShell core cmdlets, such as
            Get-Member and Get-History.

    PowerShellTrace.format.ps1xml
            Trace objects, such as those generated by the Trace-Command cmdlet.

    Registry.format.ps1xml
            Registry objects, such as keys and entries.

    A formatting file can define four different views of each object:
    table, list, wide, and complex. For example, when the output of a
    Get-ChildItem command is piped to a Format-List command, Format-List
    uses the view in the FileSystem.format.ps1xml file to determine how to
    display the file and folder objects as a list.

    In a Format.ps1xml file, a view is defined by a set of XML tags that
    describe the name of the view, the type of object to which it can
    be applied, the column headers, and the properties that are displayed
    in the body of the view. The format in Format.ps1xml files is applied
    just before the data is presented to the user.

Creating New Format.ps1xml Files

     The .ps1xml files that are installed with Windows PowerShell are
     digitally signed to prevent tampering because the formatting can include
     script blocks. Therefore, to change the display format of an existing
     object view, or to add views for new objects, create your own
     Format.ps1xml files, and then add them to your Windows PowerShell
     session.

     To create a new file, copy an existing Format.ps1xml file. The new file
     can have any name, but it must have a .ps1xml file name extension. You
     can place the new file in any directory that is accessible to Windows
     PowerShell, but it is useful to place the files in the Windows PowerShell
     installation directory ($pshome) or in a subdirectory of the installation
     directory.

     To change the formatting of a current view, locate the view in the
     formatting file, and then use the tags to change the view. To create a
     view for a new object type, create a new view, or use an existing view
     as a model. (The tags are described in the next section of this topic.)
     You can then delete all the other views in the file so that the changes
     are obvious to anyone examining the file.

     When you have saved the changes, use the Update-FormatData cmdlet to add
     the new file to your Windows PowerShell session. If you want your view
     to take precedence over a view defined in the built-in files, use the
     PrependData parameter of Update-FormatData. Update-FormatData affects
     only the current session. To make the change to all future sessions, add
     the Update-FormatData command to your Windows PowerShell profile.

Example: Adding Calendar Data to Culture Objects

     This example shows how to change the formatting of the culture objects
     (System.Globalization.CultureInfo) generated by the Get-Culture cmdlet.
     The commands in the example add the calendar property to the default
     table view display of culture objects.

     The first step is to find the Format.ps1xml file that contains the
     current view of the culture objects. The following Select-String command
     finds the file:

     Select-String -path $pshome\*format.ps1xml `
             -pattern System.Globalization.CultureInfo

     This command reveals that the definition is in the
     DotNetTypes.Format.ps1xml file.

     The next command copies the file contents to a new file,
     MyDotNetTypes.Format.ps1xml.

     Copy-Item DotNetTypes.Format.ps1xml MyDotNetTypes.Format.ps1xml

     Next, open the MyDotNetTypes.Format.ps1xml file in any XML or text
     editor, such as Notepad. Find the System.Globalization.CultureInfo object
     section. The following XML defines the views of the CultureInfo object.
     The object has only a TableControl view.

     <View>
         <Name>System.Globalization.CultureInfo</Name>
         <ViewSelectedBy>
             <TypeName>Deserialized.System.Globalization.CultureInfo</TypeName>
             <TypeName>System.Globalization.CultureInfo</TypeName>
         </ViewSelectedBy>

         <TableControl>
             <TableHeaders>
                 <TableColumnHeader>
                     <Width>16</Width>
                 </TableColumnHeader>
                 <TableColumnHeader>
                     <Width>16</Width>
                 </TableColumnHeader>
                 <TableColumnHeader/>
             </TableHeaders>
             <TableRowEntries>
                 <TableRowEntry>
                     <TableColumnItems>
                         <TableColumnItem>
                             <PropertyName>LCID</PropertyName>
                         </TableColumnItem>
                         <TableColumnItem>
                             <PropertyName>Name</PropertyName>
                         </TableColumnItem>
                         <TableColumnItem>
                             <PropertyName>DisplayName</PropertyName>
                         </TableColumnItem>
                     </TableColumnItems>
                 </TableRowEntry>
             </TableRowEntries>
         </TableControl>
     </View>

     Delete the remainder of the file, except for the opening <?XML>,
     <Configuration>, and <ViewDefinitions> tags and the closing
     <ViewDefintions> and <Configuration> tags. You must also delete the
     digital signature whenever you change the file.

     <?xml version=”1.0″ encoding=”utf-8″ ?>
     <Configuration>
         <ViewDefinitions>
             <View>
                 <Name>System.Globalization.CultureInfo</Name>
                 <ViewSelectedBy>
                     <TypeName>Deserialized.System.Globalization.CultureInfo</TypeName>
                     <TypeName>System.Globalization.CultureInfo</TypeName>
                 </ViewSelectedBy>

                 <TableControl>
                     <TableHeaders>
                         <TableColumnHeader>
                             <Width>16</Width>
                         </TableColumnHeader>
                         <TableColumnHeader>
                             <Width>16</Width>
                         </TableColumnHeader>
                         <TableColumnHeader/>
                     </TableHeaders>
                     <TableRowEntries>
                         <TableRowEntry>
                             <TableColumnItems>
                                 <TableColumnItem>
                                     <PropertyName>LCID</PropertyName>
                                 </TableColumnItem>
                                 <TableColumnItem>
                                     <PropertyName>Name</PropertyName>
                                 </TableColumnItem>
                                 <TableColumnItem>
                                     <PropertyName>DisplayName</PropertyName>
                                 </TableColumnItem>
                             </TableColumnItems>
                         </TableRowEntry>
                     </TableRowEntries>
                 </TableControl>
             </View>
         </ViewDefinitions>
     </Configuration>

     Next, create a new column for the Calendar property by adding a new set
     of <TableColumnHeader> tags. The value of the Calendar property can be
     long, so a value of 45 characters is used, as follows:

                <TableControl>
                    <TableHeaders>
                        <TableColumnHeader>
                            <Width>16</Width>
                        </TableColumnHeader>
                        <TableColumnHeader>
                            <Width>16</Width>
                        </TableColumnHeader>

                        <TableColumnHeader>
                            <Width>45</Width>
                        </TableColumnHeader>

                        <TableColumnHeader/>
                    </TableHeaders>

     Now, add a new column item in the table rows, as follows:

                <TableRowEntries>
                    <TableRowEntry>
                        <TableColumnItems>
                            <TableColumnItem>
                                <PropertyName>LCID</PropertyName>
                            </TableColumnItem>
                            <TableColumnItem>
                                <PropertyName>Name</PropertyName>
                            </TableColumnItem>

                            <TableColumnItem>
                                <PropertyName>Calendar</PropertyName>
                            </TableColumnItem>

                            <TableColumnItem>
                                <PropertyName>DisplayName</PropertyName>
                            </TableColumnItem>
                        </TableColumnItems>
                    </TableRowEntry>
                 </TableRowEntries>

     After saving the file and closing it, use an Update-FormatData command,
     such as the following command, to add the new format file to the current
     session. The command uses the PrependData parameter to place the new file
     in a higher precedence order than the original file. (For more
     information about Update-FormatData, type “Get-Help Update-FormatData“.)

     Update-FormatData -prependpath $pshome\MyDotNetTypes.format.ps1xml

     To test the change, type “Get-Culture“, and then review the output,
     which includes the Calendar property.

     C:\PS> Get-Culture

     LCID Name Calendar                             DisplayName
     —- —- ——–                             ———–
     1033 en-US System.Globalization.GregorianCalendar English (United States)

The XML in Format.ps1xml Files

     The ViewDefinitions section of each Format.ps1xml file contains the
     <View> tags that define each view. A typical <View> tag includes the
     following tags:

         <Name>
             The <Name> tag identifies the name of the view.

         <ViewSelectedBy>
             The <ViewSelectedBy> tag specifies the object type or types to
             which the view applies.

         <GroupBy>
             The <GroupBy> tag specifies how items in the view will be
             combined in groups.

         <TableControl>
         <ListControl>
         <WideControl>
         <ComplexControl>
             These tags contain the tags that specify how each item will be
             displayed.

     The <ViewSelectedBy> tag can contain a <TypeName> tag for each object
     type to which the view applies. Or, it can contain a <SelectionSetName>
     tag that references a selection set that is defined elsewhere by using
     a <SelectionSet> tag.

     The <GroupBy> tag contains a <PropertyName> tag that specifies the
     object property by which items are to be grouped. It also contains either
     a <Label> tag that specifies a string to be used as a label for each
     group or a <ComplexControlName> tag that references a complex control
     defined elsewhere using a <Control> tag. The <Control> tag contains a
     <Name> tag and a <ComplexControl> tag.

     The <TableControl> tag typically contains <TableHeaders> and
     <TableRowEntries> tags that define the formatting for the table’s heads
     and rows. The <TableHeaders> tag typically contains <TableColumnHeader>
     tags that contain <Label>, <Width>, and <Alignment> tags. The
     <TableRowEntries> tag contains <TableRowEntry> tags for each row in the
     table. The <TableRowEntry> tag contains a <TableColumnItems> tag
     that contains a <TableColumnItem> tag for each column in the row.
     Typically, the <TableColumnItem> tag contains either a <PropertyName> tag
     that identifies the object property to be displayed in the defined
     location, or a <ScriptBlock> tag that contains script code that
     calculates a result that is to be displayed in the location.

     Note: Script blocks can also be used elsewhere in locations where
            calculated results can be useful.

     The <TableColumnItem> tag can also contain a <FormatString> tag that
     specifies how the property or the calculated results will be displayed.

     The <ListControl> tag typically contains a <ListEntries> tag. The
     <ListEntries> tag contains a <ListItems> tag. The <ListItems> tag
     contains <ListItem> tags, which contain <PropertyName> tags.
     The <PropertyName> tags specify the object property to be displayed at
     the specified location in the list. If the view selection is defined
     using a selection set, the <ListControl> tag can also contain an
     <EntrySelectedBy> tag that contains one or more <TypeName> tags. These
     <TypeName> tags specify the object type that the <ListControl> tag is
     intended to display.

     The <WideControl> tag typically contains a <WideEntries> tag. The
     <WideEntries> tag contains one or more <WideEntry> tags. A <WideEntry>
     tag typically contains a <PropertyName> tag that specifies the property
     to be displayed at the specified location in the view. The <PropertyName>
     tag can contain a <FormatString> tag that specifies how the property is
     to be displayed.

     The <ComplexControl> tag contains more complex combinations of tags than
     other view types. A <ComplexControl> tag typically contains
     a <ComplexEntries> tag. A <ComplexEntries> tag contains multiple
     <ComplexEntry> tags. A <ComplexEntry> tag typically contains a
     <ComplexItem> tag. This tag, in turn, can contain a variety of tags that
     specify contents and formatting for the specified location in the view,
     including <Text>, <Indentation>, <ExpressionBinding>, and <NewLine> tags.

Update-FormatData

     To load your Format.ps1xml files into a Windows PowerShell session, use
     the Update-FormatData cmdlet. If you want the views in your file to
     take precedence over the views in the built-in Format.ps1xml file, use
     the PrependData parameter of Update-FormatData. Update-FormatData affects
     only the current session. To make the change to all future sessions, add
     the Update-FormatData command to your Windows PowerShell profile.

Default Displays in Types.ps1xml

     The default displays of some basic object types are defined in the
     Types.ps1xml file in the $pshome directory. The nodes are named
     PsStandardMembers, and the subnodes use one of the following tags:

         <DefaultDisplayProperty>
         <DefaultDisplayPropertySet>
         <DefaultKeyPropertySet>

     For more information, type the following command:

     Get-Help about_types.ps1xml

Tracing Format.ps1xml File Use

     To detect errors in the loading or application of Format.ps1xml files,
     use the Trace-Command cmdlet with any of the following format
     components as the value of the Name parameter:

     FormatFileLoading
         UpdateFormatData
         FormatViewBinding

     For more information, type the following commands:

         Get-Help Trace-Command
         Get-Help Get-TraceSource

Signing a Format.ps1xml File

     To protect the users of your Format.ps1xml file, sign the file using
     a digital signature. For more information, type:

         Get-Help about_Signing

SEE ALSO
    Update-FormatData
    Trace-Command
    Get-TraceSource

about_Foreach

TOPIC
    about_Foreach

SHORT DESCRIPTION
    Describes a language command you can use to traverse all the items in a
    collection of items.

LONG DESCRIPTION
    The Foreach statement (also known as a Foreach loop) is a language
    construct for stepping through (iterating) a series of values in a
    collection of items.

    The simplest and most typical type of collection to traverse is an array.
    Within a Foreach loop, it is common to run one or more commands against
    each item in an array.

Syntax
     The following shows the Foreach syntax:

         foreach ($<item> in $<collection>){<statement list>}

The Foreach Statement Outside a Command Pipeline
     The part of the Foreach statement enclosed in parenthesis represents a
     Variable and a collection to iterate. Windows PowerShell creates the
     Variable ($<item>) automatically when the Foreach loop runs. Prior to
     each iteration through the loop, the Variable is set to a value in the
     collection. The block following a Foreach statement {<statement list>}
     contains a set of commands to execute against each item in a collection.

Examples
     For example, the Foreach loop in the following example displays the
     values in the $letterArray array.

         $letterArray = “a”,”b”,”c”,”d”
         foreach ($letter in $letterArray)
         {
             Write-Host $letter
         }

     In this example, the $letterArray array is created and initialized with
     the string values “a”, “b”, “c”, and “d”. The first time the Foreach
     statement runs, it sets the $letter Variable equal to the first item in
     $letterArray (“a”). Then, it uses the Write-Host cmdlet to display the
     letter a. The next time through the loop, $letter is set to “b”, and so
     on. After the Foreach loop displays the letter d, Windows PowerShell
     exits the loop.

     The entire Foreach statement must appear on a single line to run it as a
     command at the Windows PowerShell command prompt. The entire Foreach
     statement does not have to appear on a single line if you place the
     command in a .ps1 script file instead.

     Foreach statements can also be used together with cmdlets that
     return a collection of items. In the following example, the Foreach
     statement steps through the list of items that is returned by the
     Get-ChildItem cmdlet.

         foreach ($file in Get-ChildItem)
         {
             Write-Host $file
         }

     You can refine the example by using an If statement to limit the results
     that are returned. In the following example, the Foreach statement
     performs the same looping operation as the previous example, but it adds
     an If statement to limit the results to files that are greater than 100
     kilobytes (KB):

         foreach ($file in Get-ChildItem)
         {
             if ($file.length -gt 100k)
             {
                 Write-Host $file
             }
         }

     In this example, the Foreach loop uses a property of the $file Variable
     to perform a comparison operation ($file.length -gt 100k). The $file
     Variable contains all the properties in the object that is returned by
     the Get-ChildItem cmdlet. Therefore, you can return more than just a
     file name. In the next example, Windows PowerShell returns the length and
     the last access time inside the statement list:

         foreach ($file in Get-ChildItem)
         {
             if ($file.length -gt 100k)
             {
                 Write-Host $file
                 Write-Host $file.length
                 Write-Host $file.lastaccesstime
             }
         }

     In this example, you are not limited to running a single command in a
     statement list.

     You can also use a Variable outside a Foreach loop and increment the
     Variable inside the loop. The following example counts files over 100 KB
     in size:

         $i = 0
         foreach ($file in Get-ChildItem)
         {
             if ($file.length -gt 100k)
             {
                 Write-Host $file “file size:” ($file.length /
         1024).ToString(“F0”) KB
                 $i = $i + 1
             }
         }

         if ($i -ne 0)
         {
             Write-Host
             Write-Host $i ” file(s) over 100 KB in the current
         directory.”}
         else
         {
             Write-Host “No files greater than 100 KB in the current
         directory.”
         }

     In the preceding example, the $i Variable is set to 0 outside the loop,
     and the Variable is incremented inside the loop for each file that is
     found that is larger than 100 KB. When the loop exits, an If statement
     evaluates the value of $i to display a count of all the files over
     100 KB. Or, it displays a message stating that no files over 100 KB were
     found.

     The previous example also demonstrates how to format the file length
     results:

         ($file.length / 1024).ToString(“F0”)

     The value is divided by 1,024 to show the results in kilobytes rather
     than bytes, and the resulting value is then formatted using the
     fixed-point format specifier to remove any decimal values from the
     result. The 0 makes the format specifier show no decimal places.

The Foreach Statement Inside a Command Pipeline
     When Foreach appears in a command pipeline, Windows PowerShell uses the
     foreach Alias, which calls the ForEach-Object command. When you use
     the foreach Alias in a command pipeline, you do not include
     the ($<item> in $<collection>) syntax as you do with the Foreach
     statement. This is because the prior command in the pipeline provides
     this information. The syntax of the foreach Alias when used in a command
     pipeline is as follows:

         <command> | foreach {<command_block>}

     For example, the Foreach loop in the following command pipeline displays
     any processes whose working set (memory usage) is greater
     than 20 megabytes (MB). Windows PowerShell pipes the output from the
     Get-Process command to the foreach Alias. Inside the foreach Alias
     command block, the $_.WS Variable contains the value of the WS (working
     set) property passed to it by the Get-Process cmdlet. (The $_ portion
     of the declaration is a Windows Script Host [WSH] automatic Variable,
     and the WS portion is a property). The If statement uses a conditional
     statement to determine whether the working set is greater than 20 MB
     (20,000,000 bytes). If so, the name of the process that is stored in
     the $_.name Variable and the working-set size in megabytes are displayed.
     If no process working set is over 20 MB, nothing is displayed.

         Write-Host “Processes with working-sets greater than 20 MB”
         Get-Process | foreach {
             if ($_.WS -gt 20m)
             {
                 Write-Host $_.name “: ”
         ($_.WS/1m).ToString(“F0”) MB -Separator “”
             }
         }

     The foreach Alias also supports beginning command blocks, middle command
     blocks, and end command blocks. The beginning and end command blocks run
     once, and the middle command block runs every time the Foreach loop steps
     through a collection or array.

     The syntax of the foreach Alias when used in a command pipeline with a
     beginning, middle, and ending set of command blocks is as follows:

         <command> | foreach {<beginning command_block>}{<middle
         command_block>}{<ending command_block>}

     The following example demonstrates the use of the beginning, middle, and
     end command blocks.

         Get-ChildItem | foreach {
         $fileCount = $directoryCount = 0}{
         if ($_.PsIsContainer) {$directoryCount++} else {$fileCount++}}{
         “$directoryCount directories and $fileCount files”}

     The beginning block creates and initializes two Variables to 0:

         {$fileCount = $directoryCount = 0}

     The middle block evaluates whether each item returned by Get-ChildItem
     is a directory or a file:

         {if ($_.PsIsContainer) {$directoryCount++} else {$fileCount++}}

     If the item that is returned is a directory, the $directoryCount
     Variable is incremented by 1. If the item is not a directory,
     the $fileCount Variable is incremented by 1. The ending block runs after
     the middle block completes its looping operation and then returns the
     results of the operation:

         {“$directoryCount directories and $fileCount files”}

     By using the beginning, middle, and ending command block structure and
     the pipeline operator, you can rewrite the earlier example to find any
     files that are greater than 100 KB, as follows:

         Get-ChildItem | foreach{
             $i = 0}{
             if ($_.length -gt 100k)
             {
                 Write-Host $_.name “file size:” ($_.length /
         1024).ToString(“F0”) KB
                 $i++
             }
             }{
             if ($i -ne 0)
             {
                 Write-Host
                 Write-Host “$i file(s) over 100 KB in the current
         directory.”
             }
             else
             {
             Write-Host “No files greater than 100 KB in the current
         directory.”}
             }

SEE ALSO
    about_Automatic_Variables
    about_If
    ForEach-Object

about_For

TOPIC
    about_For

SHORT DESCRIPTION
    Describes a language command you can use to run statements based on a
    conditional test.

LONG DESCRIPTION
    The For statement (also known as a For loop) is a language construct
    you can use to create a loop that runs commands in a command block while a
    specified condition evaluates to true.

    A typical use of the For loop is to iterate an array of values and to
    operate on a subset of these values. In most cases, if you want to
    iterate all the values in an array, consider using a Foreach statement.

Syntax
     The following shows the For statement syntax.

         for (<init>; <condition>; <repeat>)
         {<statement list>}

     The <init> placeholder represents one or more commands, separated by
     commas, that are run before the loop begins. You typically use the
     <init> portion of the statement to create and initialize a Variable with
     a starting value.

     This Variable will then be the basis for the condition to be tested in
     the next portion of the For statement.

     The <condition> placeholder represents the portion of the For statement
     that resolves to a true or false Boolean value. Windows PowerShell
     evaluates the condition each time the For loop runs. If the statement is
     true, the commands in the command block run, and the statement is
     evaluated again. If the condition is still true, the commands in the
     statement list run again. The loop is repeated until the condition
     becomes false.

     The <repeat> placeholder represents one or more commands, separated by
     commas, that are executed each time the loop repeats. Typically, this
     is used to modify a Variable that is tested inside the <condition> part
     of the statement.

     The <statement list> placeholder represents a set of one or more commands
     that are run each time the loop is entered or repeated. The contents of
     the statement list are surrounded by braces.

Examples
     At a minimum, a For statement requires the parenthesis surrounding the
     <init>, <condition>, and <repeat> part of the statement and a command
     surrounded by braces in the <statement list> part of the statement.

     Note that the upcoming examples intentionally show code outside the
     For statement. In later examples, code is integrated into the for
     statement.

     For example, the following For statement continually displays the
     value of the $i Variable until you manually break out of the command by
     pressing CTRL+C.

         $i = 1
         for (;;){Write-Host $i}

     You can add additional commands to the statement list so that
     the value of $i is incremented by 1 each time the loop is run, as the
     following example shows.

         for (;;){$i++; Write-Host $i}

     Until you break out of the command by pressing CTRL+C, this statement
     will continually display the value of the $i Variable as it is
     incremented by 1 each time the loop is run.

     Rather than change the value of the Variable in the statement list
     part of the For statement, you can use the <repeat> portion of the For
     statement instead, as follows.

         $i=1
         for (;;$i++){Write-Host $i}

     This statement will still repeat indefinitely until you break out of the
     command by pressing CTRL+C.

     By setting a condition (using the <condition> portion of the For
     statement), you can end the For loop when the condition evaluates to
     false. In the following example, the For loop runs while the value of
     $i is less than or equal to 10.

         $i=1
         for(;$i -le 10;$i++){Write-Host $i}

     Instead of creating and initializing the Variable outside the For
     statement, you can perform this task inside the For loop by using
     the <init> portion of the For statement.

         for($i=1; $i -le 10; $i++){Write-Host $i}

     You can use carriage returns instead of semicolons to delimit the
     <init>, <condition>, and <repeat> portions of the For statement. The
     following example shows the For statement syntax in this alternative
     form.

            for (<init>
         <condition>
         <repeat>){
         <statement list>
         }

     This alternative form of the For statement works in Windows PowerShell
     script files and at the Windows PowerShell command prompt. However, it
     is easier to use the For statement syntax with semicolons when you enter
     interactive commands at the command prompt.

     The For loop is more flexible than the Foreach loop because it allows
     you to increment values in an array or collection by using patterns. In
     the following example, the $i Variable is incremented by 2 in the
     <repeat> portion of the for statement.

         for ($i = 0; $i -ile 20; $i += 2) {Write-Host $i}

SEE ALSO
    about_Comparison_Operators
    about_Foreach

about_execution_policies

TOPIC
    about_execution_policies

SHORT DESCRIPTION
    Describes the Windows PowerShell execution policies and explains
    how to manage them.

LONG DESCRIPTION
    Windows PowerShell execution policies let you determine the
    conditions under which Windows PowerShell loads configuration files
    and runs scripts.

    You can set an execution policy for the local computer, for the current
    user, or for a particular session. You can also use a Group Policy
    setting to set execution policy for computers and users.

    Execution policies for the local computer and current user are stored
    in the Registry. You do not need to set execution policies in your
    Windows PowerShell profile. The execution policy for a particular session
    is stored only in memory and is lost when the session is closed.

    The execution policy is not a security system that restricts user actions.
    For example, users can easily circumvent a policy by typing the script
    contents at the command line when they cannot run a script. Instead, the
    execution policy helps users to set basic rules and prevents them from
    violating them unintentionally.

WINDOWS POWERSHELL EXECUTION POLICIES
————————————-

    The Windows PowerShell execution policies are as follows:

    “Restricted” is the default policy.

        Restricted
            – Default execution policy.

            – Permits individual commands, but will not run
             scripts.

            – Prevents running of all script files, including
             formatting and configuration files (.ps1xml), module
             script files (.psm1), and Windows PowerShell
             profiles (.ps1).

        AllSigned
            – Scripts can run.

            – Requires that all scripts and configuration files
             be signed by a trusted publisher, including scripts
             that you write on the local computer.

            – Prompts you before running scripts from publishers
             that you have not yet classified as trusted or
             untrusted.

            – Risks running unsigned scripts from sources other
             than the Internet and signed, but malicious, scripts.

        RemoteSigned
            – Scripts can run.

            – Requires a digital signature from a trusted
             publisher on scripts and configuration files that
             are downloaded from the Internet (including
             e-mail and instant messaging programs).

            – Does not require digital signatures on scripts that you have run
             and that you have written on the local computer (not
             downloaded from the Internet).

            – Risks running signed, but malicious, scripts.

        Unrestricted
            – Unsigned scripts can run. (This risks running malicious
             scripts.)

            – Warns the user before running srcipts and configuration
             files that are downloaded from the Internet.

        Bypass
            – Nothing is blocked and there are no warnings or
             prompts.

            – This execution policy is designed for configurations
             in which a Windows PowerShell script is built in to a
             a larger application or for configurations in which
             Windows PowerShell is the foundation for a program
             that has its own security model.

        Undefined
            – There is no execution policy set in the current scope.

            – If the execution policy in all scopes is Undefined, the
             effective execution policy is Restricted, which is the
             default execution policy.

    Note: On systems that do not distinguish Universal Naming Convention (UNC)
         paths from Internet paths, scripts that are identified by a UNC path
         might not be permitted to run with the RemoteSigned execution policy.

EXECUTION POLICY SCOPE
———————-
    You can set an execution policy that is effective only in a
    particular scope.

    The valid values for Scope are Process, CurrentUser, and
    LocalMachine. LocalMachine is the default when setting an
    execution policy.

    The Scope values are listed in precedence order.

        – Process
             The execution policy affects only the current session
             (the current Windows PowerShell process). The execution
             policy is stored in the $PSExecutionPolicyPreference
             Environment Variable. This value is deleted when the
             session in which the policy is set is closed.

        – CurrentUser
             The execution policy affects only the current user. It
             is stored in the HKEY_CURRENT_USER Registry subkey.

        – LocalMachine
             The execution policy affects all users on the current
             computer. It is stored in the HKEY_LOCAL_MACHINE
             Registry subkey.

    The policy that takes precedence is effective in the current
    session, even if a more restrictive policy was set at a lower
    level of precedence.

    For more information, see Set-ExecutionPolicy.

GET YOUR EXECUTION POLICY
——————————
    To get the Windows PowerShell execution policy that is in
    effect in the current session, use the Get-ExecutionPolicy cmdlet.

    The following command gets the current execution policy:

    Get-ExecutionPolicy

    To get all of the execution policies that affect the current
    session and displays them in precedence order, type:

        Get-ExecutionPolicy -list

    The result will look similar to the following sample output:

                 Scope    ExecutionPolicy
                 —–    —————
         MachinePolicy         Undefined
             UserPolicy         Undefined
                Process         Undefined
            CurrentUser     RemoteSigned
         LocalMachine         AllSigned

    In this case, the effective execution policy is RemoteSigned
    because the execution policy for the current user takes precedence
    over the execution policy set for the local computer.

    To get the execution policy set for a particular scope, use the
    Scope parameter of Get-ExecutionPolicy.

    For example, the following command gets the execution policy for
    the current user scope.

        Get-ExecutionPolicy -scope CurrentUser

CHANGE YOUR EXECUTION POLICY
——————————
    To change the Windows PowerShell execution policy on your
    computer, use the Set-ExecutionPolicy cmdlet.

    The change is effective immediately; you do not need to restart
    Windows PowerShell.

    If you set the execution policy for the local computer (the default)
    or the current user, the change is saved in the Registry and remains
    effective until you change it again.

    If you set the execution policy for the current process, it is
    not saved in the Registry. It is retained until the current
    process and any child processes are closed.

    Note: In Windows Vista and later versions of Windows, to run
         commands that change the execution policy for the local
         computer (the default), start Windows PowerShell with the
         “Run as administrator” option.

    To change your execution policy, type:

        Set-ExecutionPolicy <policy-name>

    For example:

        Set-ExecutionPolicy RemoteSigned

    To set the execution policy in a particular scope, type:

        Set-ExecutionPolicy <policy-name> -scope <scope>

    For example:

        Set-ExecutionPolicy RemoteSigned -scope CurrentUser

    A command to change an execution policy can succeed but
    still not change the effective execution policy.

    For example, a command that sets the execution policy for
    the local computer can succeed but be overridden by the
    execution policy for the current user.

REMOVE YOUR EXECUTION POLICY
—————————-
    To remove the execution policy for a particular scope, set
    the value of the value of the execution policy to Undefined.

    For example, to remove the execution policy for all the users of
    the local computer, type:

        Set-ExecutionPolicy Undefined

    Or, type:

        Set-ExecutionPolicy Undefined -scope LocalMachine

    If no execution policy is set in any scope, the effective
    execution policy is Restricted, which is the default.

SET AN EXECUTION POLICY IN POWERSHELL.EXE
—————————————–
    You can use the ExecutionPolicy parameter of PowerShell.exe to
    set an execution policy for a new Windows PowerShell session.
    The policy affects only the current session and child sessions.

    To set the execution policy for a new session, start Windows PowerShell
    at the command line (such as Cmd.exe or Windows PowerShell), and then use
    the ExecutionPolicy parameter of PowerShell.exe to set the execution
    policy.

    For example:

    powershell.exe -executionpolicy -allsigned

    The execution policy that you set is not stored in the Registry.
    Instead, it is stored in the $PSExecutionPolicyPreference Environment
    Variable. The Variable is deleted when you close the session in which the
    policy is set.

    During the session, the execution policy that is set for the session takes
    precedence over an execution policy that is set in the Registry for the
    local computer or current user. However, it does not take precedence over
    the execution policy set by using a Group Policy setting (discussed below).

USE GROUP POLICY TO MANAGE EXECUTION POLICY
——————————————-
    You can use the “Turn on Script Execution” Group Policy setting
    to manage the execution policy of computers in your enterprise.
    The Group Policy setting overrides the execution policies set in Windows
    PowerShell in all scopes.

    The “Turn on Script Execution” policy settings are as follows:

    — If you disable “Turn on Script Execution”, scripts do not run.
     This is equivalent to the “Restricted” execution policy.

    — If you enable “Turn on Script Execution”, you can select an
     execution policy. The Group Policy settings are equivalent to
     the following execution policy settings.

        Group Policy                Execution Policy
        ————                —————-
        Allow all scripts.         Unrestricted

        Allow local scripts         RemoteSigned
        and remote signed
        scripts.

        Allow only signed         AllSigned
        scripts.

    — If “Turn on Script Execution” is not configured, it has no
     effect. The execution policy set in Windows PowerShell is
     effective.

    The PowerShellExecutionPolicy.adm file adds the
    “Turn on Script Execution” policy to the Computer Configuration
    and User Configuration nodes in Group Policy Editor in the following
    paths.

        For Windows XP and Windows Server 2003:
        Administrative Templates\Windows Components\Windows PowerShell

        For Windows Vista and later versions of Windows:
        Administrative Templates\Classic Administrative Templates\
        Windows Components\Windows PowerShell

    Policies set in the Computer Configuration node take precedence
    over policies set in the User Configuration node.

    The PowerShellExecutionPolicy.adm file is available on the
    Microsoft Download Center. For more information, see “Administrative
    Templates for Windows PowerShell” at
    http://go.microsoft.com/fwlink/?LinkId=131786.

EXECUTION POLICY PRECEDENCE
—————————
    When determining the effective execution policy for a
    session, Windows PowerShell evaluates the execution policies
    in the following precedence order:

        – Group Policy: Computer Configuration
        – Group Policy: User Configuration
        – Execution Policy: Process (or PowerShell.exe -ExecutionPolicy)
        – Execution Policy: CurrentUser
        – Execution Policy: LocalMachine

MANAGE SIGNED AND UNSIGNED SCRIPTS
———————————-
    If your Windows PowerShell execution policy is RemoteSigned,
    Windows PowerShell will not run unsigned scripts that are
    downloaded from the Internet (including e-mail and instant
    messaging programs).

    You can sign the script or elect to run an unsigned script
    without changing the execution policy.

    For more information, see about_Signing.

SEE ALSO
    Get-ExecutionPolicy
    Set-ExecutionPolicy
    about_Signing
    “Administrative Templates for Windows PowerShell”
        (http://go.microsoft.com/fwlink/?LinkId=131786)

about_eventlogs

TOPIC
    about_eventlogs

SHORT DESCRIPTION
    Windows PowerShell creates a Windows event log that is
    named “Windows PowerShell” to record Windows PowerShell events. You can
    view this log in Event Viewer or by using cmdlets that get events, such as
    the Get-EventLog cmdlet. By default, Windows PowerShell engine and provider
    events are recorded in the event log, but you can use the event log
    preference Variables to customize the event log. For example, you can add
    events about Windows PowerShell commands.

LONG DESCRIPTION
    The Windows PowerShell event log records details of Windows PowerShell
    operations, such as starting and stopping the program engine and starting
    and stopping the Windows PowerShell providers. You can also log details
    about Windows PowerShell commands.

    In Windows Vista and later versions, the Windows PowerShell event log
    is in the Application and Services Logs group. The Windows PowerShell log
    is a classic event log that does not use the Windows Eventing technology.
    To view the log, use the cmdlets designed for classic event logs, such as
    Get-EventLog.

Viewing the Windows PowerShell Event Log

     You can view the Windows PowerShell event log in Event Viewer or by
     using the Get-EventLog and Get-WmiObject cmdlets. To view the contents
     of the Windows PowerShell log, type:

     Get-Eventlog -logname “Windows PowerShell”

     To examine the events and their properties, use the Sort-Object cmdlet,
     the Group-Object cmdlet, and the cmdlets that contain the Format verb
     (the Format cmdlets).

     For example, to view the events in the log grouped by the event ID, type:

     Get-Eventlog “Windows PowerShell” | Format-Table -groupby eventid

     Or, type:

     Get-Eventlog “Windows PowerShell” | Sort-Object eventid `
            | Group-Object eventid

     To view all the classic event logs, type:

     Get-Eventlog -list

     You can also use the Get-WmiObject cmdlet to use the event-related
     Windows Management Instumentation (WMI) classes to examine the event log.
     For example, to view all the properties of the event log file, type:

     Get-WmiObject win32_nteventlogfile | where `
            {$_.logfilename -eq “Windows PowerShell”} | Format-List -property *

     To find the Win32 event-related WMI classes, type:

    Get-WmiObject -list | where {$_.name -like “win32*event*”}

     For more information, type “Get-Help Get-Eventlog” and
     “Get-Help Get-WmiObject“.

Selecting Events for the Windows PowerShell Event Log

     You can use the event log preference Variables to determine which events
     are recorded in the Windows PowerShell event log.

     There are six event log preference Variables; two Variables for each of
     the three logging components: the engine (the Windows PowerShell
     program), the providers, and the commands. The LifeCycleEvent Variables
     log normal starting and stopping events. The Health Variables log error
     events.

     The following table lists the event log preference Variables.

         Variable                     Description
         ————————– —————————————-

     $LogEngineLifeCycleEvent     Logs starting and stopping of
                                     Windows PowerShell.

     $LogEngineHealthEvent        Logs Windows PowerShell program errors.

     $LogProviderLifeCycleEvent Logs starting and stopping of
                                     Windows PowerShell providers.

     $LogProviderHealthEvent     Logs Windows PowerShell provider errors.

     $LogCommandLifeCycleEvent    Logs starting and completion of commands.

     $LogCommandHealthEvent     Logs command errors.

     (For information about Windows PowerShell providers,
     type: “Get-Help about_providers“.)

     By default, only the following event types are enabled:

     $LogEngineLifeCycleEvent
     $LogEngineHealthEvent
     $LogProviderLifeCycleEvent
     $LogProviderHealthEvent

     To enable an event type, set the preference Variable for that event type
     to $true. For example, to enable command life-cycle events, type:

     $LogCommandLifeCycleEvent

     Or, type:

     $LogCommandLifeCycleEvent = $true

     To disable an event type, set the preference Variable for that event type
     to $false. For example, to disable command life-cycle events, type:

     $LogProviderLifeCycleEvent = $false

     The Variable settings apply only for the current Windows PowerShell
     session. To apply them to all Windows PowerShell sessions, add them to
     your Windows PowerShell profile.

Security and Auditing

     The Windows PowerShell event log is designed to indicate activity and
     to provide operational details for troubleshooting.

     However, like most Windows-based application event logs, the
     Windows PowerShell event log is not designed to be secure. It should not
     be used to audit security or to record confidential or proprietary
     information.

     Event logs are designed to be read and understood by users. Users can
     read from and write to the log. A malicious user could read an event log
     on a local or remote computer, record false data, and then prevent the
     logging of their activities.

SEE ALSO
    Get-EventLog
    Get-WmiObject
    about_preference_variables