The following sample syntax shows the three keywords:. If your function defines a Begin , Process or End block, all of your code must reside inside those blocks.
No code will be recognized outside the blocks if any of the blocks are defined. The Process statement list runs one time for each object in the pipeline. 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:. To demonstrate this function, enter an list of numbers separated by commas, as shown in the following example:. 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.
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. The following example has a Process statement list:. 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. For more information, see Using Enumerators.
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 following filter takes log entries from the pipeline and then displays either the whole entry or only the message portion of the entry:.
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:. 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. All the functions and filters in PowerShell are automatically stored in the Function: drive. This drive is exposed by the 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 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 PowerShell, type:.
For more information about the Function: drive, see the help topic for the Function provider. Type Get-Help Function. When you type a function at the PowerShell command prompt, the function becomes part of the current session. It is available until the session ends. To use your function in all PowerShell sessions, add the function to your PowerShell profile.
You can also save your function in a PowerShell script file. Type your function in a text file, and then save the file with the. For simple types, such as System. Version , the copy is exact.
For complex types, the copy is imperfect. For example, rehydrated certificate objects do not include the private key. Instances of all other types are PSObject instances. Variables and aliases have an Option property that can take a value of AllScope. Items that have the AllScope property become part of any child scopes that you create, although they are not retroactively inherited by parent scopes.
An item that has the AllScope property is visible in the child scope, and it is part of that scope. Changes to the item in any scope affect all the scopes in which the variable is defined. Several cmdlets have a Scope parameter that lets you get or set create and change items in a particular scope.
Use the following command to find all the cmdlets in your session that have a Scope parameter:. To find the variables that are visible in a particular scope, use the Scope parameter of Get-Variable. The visible variables include global variables, variables in the parent scope, and variables in the current scope. To create a variable in a particular scope, use a scope modifier or the Scope parameter of Set-Variable.
The following command creates a variable in the global scope:. The following command creates an alias in the global scope:. To get the functions in a particular scope, use the Get-Item cmdlet when you are in the scope.
The Get-Item cmdlet does not have a Scope parameter. For the cmdlets that use the Scope parameter, you can also refer to scopes by number. The number describes the relative position of one scope to another. Scope 0 represents the current, or local, scope. Scope 1 indicates the immediate parent scope.
Scope 2 indicates the parent of the parent scope, and so on. Numbered scopes are useful if you have created many recursive scopes. Scripts and functions follow all the rules of scope. You create them in a particular scope, and they affect only that scope unless you use a cmdlet parameter or a scope modifier to change that scope. But, you can add a script or function to the current scope by using dot source notation.
Then, when a script runs in the current scope, any functions, aliases, and variables that the script creates are available in the current scope. To add a function to the current scope, type a dot. For example, to run the Sample. The following example uses the call operator:. Any aliases, functions, or variables that the Sample. A few PowerShell concepts are similar to scope or interact with scope.
These concepts may be confused with scope or the behavior of scope. Sessions, modules, and nested prompts are self-contained environments, but they are not child scopes of the global scope in the session. A session is an environment in which PowerShell runs. When you create a session on a remote computer, PowerShell establishes a persistent connection to the remote computer.
The persistent connection lets you use the session for multiple related commands. Because a session is a contained environment, it has its own scope, but a session is not a child scope of the session in which it was created. The session starts with its own global scope. This scope is independent of the global scope of the session. You can create child scopes in the session. For example, you can run a script to create a child scope in a session. You can use a PowerShell module to share and deliver PowerShell tools.
A module is a unit that can contain cmdlets, scripts, functions, variables, aliases, and other useful items. Unless explicitly defined, the items in a module are not accessible outside the module.
Therefore, you can add the module to your session and use the public items without worrying that the other items might override the cmdlets, scripts, functions, and other items in your session. By default, modules are loaded into the top-level of the current session state not the current scope. The current session state could be a module session state or the global session state. Adding a module to a session does not change the scope. If you are in the global scope, then modules are loaded into the global session state.
Any exports are placed into the global tables. If you load module2 from within module1, module2 is loaded into the session state of module1 not the global session state. Any exports from module2 are placed at the top of the module1 session state. If you use Import-Module -Scope local , then the exports are placed into the current scope object rather than at the top level.
Similarly, the function can be deleted just as a file would be deleted using the rm command. Since we are at the end of the chapter, we can now safely delete the functions created in the preceding sections:.
Functions are not persistent across Windows PowerShell sessions. In other words, if you define a function from within the Windows PowerShell interactive shell environment and then exit the session, the function will no longer exist in future sessions.
One way of quickly re-loading predefined functions is to place them into a script file and then load that script file from within the shell environment. The way this works isn't quite as most people might expect so this issue needs a little explanation. For the purposes of this description, we will create a simple function in a script file called myfunction.
Ordinarily, a script file is loaded and executed simply by referencing the name of the script at the PowerShell prompt. In fact, when this is performed, PowerShell executes the commands in the script and then discards any new settings, functions and variables once the script exists.
So executing our myfunction. In order to have the settings, functions and variables from a script file retained, it is necessary to perform a task known as dotting the script file also known as sourcing in the UNIX and Linux worlds. This is achieved by prefixing the script name with a dot and a space as follows:. As illustrated above, the function is now retained in the Windows PowerShell session. This technique applies equally to variables and any other settings that may be included in a script file which is subsequently dotted.
Jump to: navigation , search. Navigation menu Personal tools. Namespaces Page Discussion. Views Read View source View history. This page was last modified on 27 October , at
0コメント