Powershell_ 0 Basic Self-study courses _5_ the basics of customizing the PowerShell environment and PowerShell

Powershell_ 0 Basic Self-study courses _5_ the basics of customizing the PowerShell environment and PowerShell

As far as I know, the cmd shell under Windows can change the environment variables in addition to modifying the system parameters, its environment is relatively difficult to customize, and in the Linux environment, you can modify/ Some configuration files in the ETC directory to achieve the purpose of configuring the shell environment. Perhaps this is also some people criticized the cmd shell function is not strong
One of the reasons.
The current situation in Windows PowerShell has been improved, it can be said that the functionality of the custom environment provided in PS can basically be compared with the Linux environment, today we will see how to customize the shell environment in PS, first of all to look at a few concepts.
1. Scripts
In a shell such as CMD, bash, scripts can be simply understood as a collection of commands that will be executed in sequence. Many scripts have been supported in Windows before, such as:
Bat scripts, VB scripts, Java scripts, WMI scripts, Windows provides an execution hosting environment for these scripts, often called WSH (Windows Script Host). You can also implement more powerful scripts, such as Python, Perl, and more, by extending some of the three-party tools.
PS also supports the concept of scripting, the PS script is a collection of cmdlets that will be executed sequentially, and the extension of the script file in Windows is PSL.
2. Execution strategy
As the name implies, execution policy refers to the rules that the executable needs to follow during the start of execution, the execution of policies in PS determines whether the script file can be executed, and if the foot instinct is executed, the execution policy also determines whether the executed script needs to be digitally signed, and also determines whether the script configuration file can be loaded.
2, 1 View execution policy
Use the cmdlet get-executionpolicies in PS to see the execution strategy of the PS script. As shown below:
Exp:
PS c:\users\vol_20120330> Get-executionpolicy
RemoteSigned

The result of the execution above indicates that the current script execution policy is remotesigned. As mentioned above, PS has a kind of execution strategy, which is no longer explained here, but can also be obtained by using the following cmdlet:
Get-help about_execution_policies

Exp:

PS c:\users\vol_20120330> get-help about_execution_policies Topic about_execution_policies Short Description Description Windows PowerShell Executes policies and describes how to manage them.    Detailed instructions for using Windows PowerShell execution policy, you can determine the conditions under which Windows PowerShell loads the configuration file and runs the script. You can set execution policies for the local computer, the current user, or a specific session.    You can also use Group Policy settings to set execution policies for computers and users. The execution policy for the local computer and the current user is stored in the registry. You do not have to set the execution policy in the Windows PowerShell configuration file.    The execution policy for a specific session is stored only in memory, and the execution policy is lost when the session is closed. Executing a policy is not a security system that restricts user action. For example, when a script cannot be run, a user can easily circumvent a policy by typing the contents of the script on the command line. The real purpose of the execution strategy is to help the user set up some basic rules and prevent users from inadvertently violating those rules.        Windows PowerShell executes policies-------------------------------------Windows PowerShell executes the policy as follows: "Restricted" is the default policy.            Restricted-The default execution policy.            -Allows a single command to run, but cannot run the script.            -Blocks all script files from running, including format and configuration files (. ps1xml), module script files (. psm1), and Windows PowerShell configuration files (. ps1).            AllSigned-You can run the script.            -Requires that all scripts and configuration files be signed by a trusted publisher, including scripts written on the local computer.            -Prompt before running a script from a publisher that has not been categorized as trusted or untrusted.              -There is a risk of running unsigned scripts and signed but malicious scripts from sources other than the Internet.       RemoteSigned     -You can run the script.            -Require trusted publishers to digitally sign scripts and configuration files downloaded from the Internet, including e-mail and instant messaging programs.            -Do not require a digital signature for scripts that are already running and that have been written on the local computer (not downloaded from the Internet).        -Face the risk of running signed but malicious scripts. Unrestricted-You can run unsigned scripts. (risks associated with running a malicious script.)        -warns the user before running scripts and configuration files downloaded from the Internet.            Bypass-does not block any execution and does not display warnings and prompts.        -This execution policy is designed for two configurations: one is built into a larger application in Windows PowerShell scripts, and Windows PowerShell is the basis for a program that has its own security model.            Undefined-Execution policy is not set in the current scope. -If the execution policy in all scopes is Undefined, the effective execution policy is Restricted and the policy is the default execution policy.

The above command shows that the default execution policy is restricted; the execution of the script is not allowed, and the execution policy configuration information I get earlier is implemented by the following cmdlet:

Exp:

Set-executionpolicy

Set-executionpolicy remotesigned

The specific setup method can be used to get help yourself.

We know that after you set some functions, aliases, and variables in the current session, if you exit the current session, those settings will no longer be valid, and the setting execution policy is different because the execution policy information is saved in the Windows

Registry information, so that when you exit the current session, the modified execution policy information will still be valid, even if you uninstall and then reinstall PS, leaving the original settings intact.

3. Configuration files

The PS environment has 4 configuration files by default, which are described in one of the following.

3, 1 for all users, affect all shell configuration files

This configuration file is stored in:%WINDIR%\SYSTEM32\WINDOWSPOWERSHELL\V1.0\PROFILE.PSL

Modifying this configuration file will affect all users, as well as all shells.

3, 2 for all users, only affects the Windows PowerShell configuration file

This configuration file is guaranteed to exist:%WINDIR%\SYSTEM32\WINDOWSPOWERSHELL\V1.0\MICROSOFT.POWERSHELL_PFROFILE.PSL

Modifying this configuration file will affect all users, but only for Windows PowerShell.

3, 3 for the current user, affecting all shell user profiles

This configuration file is guaranteed to exist:%USERPROFILE%\My DOCUMENTS\WINDOWSPOWERSHELL\V1.0\PROFILE.PSL

Modifying this configuration file is only valid for the current user, but affects all shells

3, 4 for the current user, only affect the PS user profile

This configuration file is guaranteed to exist:%USERPROFILE%\My DOCUMENTS\WINDOWSPOWERSHELL\V1.0\MICROSOFT.POWESHEL_PROFILE.PSL

Modifying this configuration file is only valid for the current user and only affects PS.

I estimate that you will remember that I have modified this configuration file in the previous article. The path is: $path the path where the variable is stored.

3, 5 configuration file path

So many configuration files, in the current session in the end which role?

The answer to this question is that only the configuration file with the same path as the one stored in the $path variable will work, including the path and file name.

4. Create a configuration file

We know that in the Linux environment, the configuration files located in the/etc directory are generated by most systems, whereas in PS, the configuration files are not generated automatically and need to be created manually by the user. So in order to customize the environment of PS

We need to create the relevant configuration file ourselves, and we'll show you how to create a configuration file.

In the PS environment, we create a configuration file with the New-item cmdlet. As shown below:

Exp:

  New-item   -path   %env:windir%\system32\windowspowershell\v1.0\profile.psl   -itemtype file  -force

With the above command, we create a user profile that affects all users and all shells, and we can edit this profile through Notepad or the PS ISE IDE environment, I personally recommend using the IDE environment

To edit the configuration file (although, many times, some people are not very supportive of learning to program in the IDE environment, but I personally think that we can learn in the form of the CLI, but the actual development of the IDE is still high efficiency).

5. Detect if the configuration file exists

Sometimes we do not know whether there is a configuration file on a computer, if you create a configuration file directly, you may overwrite the configuration file in the system, so it is necessary to detect if there is a configuration before creating

File.

Of course, it can be viewed through a layer of open folders, but is there a simpler way? The answer is: This can have, really can have.

In PS we use the Test-path cmdlet to detect whether a configuration file exists.

Exp:

Test-path  $profile

This command returns TRUE when the $profile configuration file is present ; This command returns FALSEwhen the $profile configuration file does not exist.

Note: Using this command in an ISE environment may not be the same as the command you get when used in PS.

6. Basic Concepts in PowerShell

6, 1 Standard parameters

In traditional shell commands, each command uses different parameters and does not have consistency, whereas in PS, a set of standard parameters is provided, which facilitates learning and using cmdlets.

When using a parameter in PS, you must precede the parameter with a "-" symbol, indicating that the following identifier is a parameter; for example: Get-help-name Get-item; where name is the parameter, but the

The "-" must be added, indicating that this is a parameter.

6, 2 Help parameters

All cmdlets used? parameter to indicate that the help information needs to be output, but the cmdlet is not executed

6, 3 General parameters

Windows PowerShell provides some common parameters, because these parameters are controlled by the PS interpretation engine, so when the cmdlet implements these parameters, it will behave the same way. Common parameters include

WhatIf, confirm, verbose, debug, Warn, ErrorAction, errorvarible, outvariable, and Outbuffer.

6.4 Recommended parameters

The PS core cmdlets use standard names for similar parameters, although they are optional, but using the recommended parameters will help standardize the development of cmdlets. Recommended parameters include: Force, exclude,

Include, Passthre, Path, and casesensitive.

7. Summary

The current contacts are some of the basic content, need to slowly experience, will slowly explain some of the content of WMI management.

Powershell_ 0 Basic Self-study courses _5_ the basics of customizing the PowerShell environment and PowerShell