Not the same command line – Windows PowerShell Introduction (reprint)

Reproduced from http://www.cnblogs.com/grapeot/archive/2010/02/22/1670822.html, thank Bo Master.

Introduction

Always admired the Linux command prompt (of course they are called shell). Regular expressions, pipelines, and a variety of magical commands can be combined to perform many complex tasks efficiently. Efficiency is really high. After the saliva of the N-year, I finally had the privilege of using Win7, and met the upgraded version of CMD: Windows PowerShell. From then on, the original Windows also have such a tool AH ~
Look at the following Windows script, less than 15 lines of valid code. Under Win7, just right-click the script file and select Run with PowerShell to automatically find the 10 processes that make up the most memory, and then draw the memory they occupy into a three-dimensional pie chart, as shown in.

Press CTRL + C to copy the code

Press CTRL + C to copy the code

(1. This script calls the COM library of Excel. 2. From the point of view of command coupling, of course, the output is more advantageous than the text format, but this example mainly wants to illustrate the power of PowerShell and the excellent reusability of Microsoft products. 3. To start PowerShell manually, you can type PowerShell return directly in the search box in the Start menu.
After simply appreciating the power of PowerShell, here are a few things to look at PowerShell's advantages over previous versions of the command prompt and even the Linux shell.

Cmdlet + Regex + Pipeline + ...

In the past, there are many shortcomings of CMD compared to shell, such as less command, partial command function, and no support for regular expression. But now PowerShell catches up a lot. 2.0 RTM version built-in support for 414 commands (the term called cmdlets), support for regular expressions , powerful pipeline applications (in fact, the pipeline itself is almost the same function as before, the key is to come up with a bunch of pipes can be used to command, such as more, sort, foreach, etc.), and the system is more closely related to the previous.
Give a few examples to illustrate:
dir registry::hkey_current_user can directly display the contents of the registry corresponding location, you can see the function of Dir improved a lot.
ps | sort ws-descending | Select-first can show the 10 most memory-intensive processes, and can see the flexible application of the pipeline.
dir-name |? {$_-match "(? <num>.). * (\k<num>) "} can display files with duplicate characters in the current directory. such as ABCDA.EFG, while ABCD.EFG is not displayed. You can see that PowerShell support for regular expressions is quite powerful. (to be exact, strict regular expressions are no longer able to achieve such an effect and require context-independent grammars to support it.) ）
Previously in order to demonstrate the power of the Linux shell, Stephenjy sent a own, before meeting PowerShell feel good magic, fortunately now can be achieved. :-)

(In order to save the display space, some of the PowerShell display results are deleted, but this prompt effect can be verified with the following script: function prompt {"($env: Username)-($env: ComputerName)-(' $?: $ ?) -(Jobs: $ ((get-job | measure). Count))-($ (get-location)) ' N (! $ ((history) [-1]). ID + 1) "}

Big kill device-Object oriented

The design idea of Linux determines that all inputs and outputs are as text-formatted as possible, which facilitates collaboration between processes. It also requires that each program provide a certain amount of text parsing capability. But unlike windows, many of the inputs and outputs in PowerShell are not normal text (plain text), but rather an object (objects). PowerShell is therefore not so much an interactive environment as it is the runtime of a powerful language, and this language is even object-oriented.
For example, when you type get-process to view the list of current processes, the system returns a list of these:

handles  NPM (k)     PM (k)       WS (k) VMs (M)    CPU (s)       Id ProcessName
------- ------   -----     --- -------  ------    -------------
    318        8    12948       3872    84             1728 applemobiled
    115        5    13816      13328    38             6920 AUDIODG
   1315       21    11732      10988   108             2544 CcmExec
...

Although it appears to be a typical formatted text, it is an array, and each array element is an object of the process type. With. NET same strain, all classes in PowerShell inherit from Object, and the GetType () function is supported. So we can execute (get-process). GetType () to see the type of it:

IsPublic isserial Name BaseType
-------- -------- ----                                     --------
True true object[] System.Array

The type of each element in the array can be used (get-process) [0]. GetType () View:

IsPublic isserial Name BaseType
-------- -------- ----                                     --------
True False Process System.componentm ...

The thought-oriented thinking is very obvious, and the class members, methods, and inheritance all appear. The benefit of personal feeling is not to expect to be able to write big software with PowerShell, but in two other ways: first, this makes the built-in cmdlets and their data structures clear, intuitive, and fast and error -prone when writing code. Second, the object-oriented built-in support is also seamlessly bonded behind. NET and COM interfaces provide the foundation.

Standing on the shoulders of giants--seamlessly called. net/com

The. NET framework contains an exceptionally powerful library, and many libraries are encapsulated in COM to ensure cross-language compatibility at the binary level. One of the great features of PowerShell is that you can call these libraries directly. As the previous example creates an Excel object with $objexcel = New-object-comobject Excel.Application. A script on Wikipedia demonstrates the power of this seamless invocation. Here's a 3-sentence script that shows the title of the last 8 articles in an RSS feed. Note that the network connection, content download, XML parsing and so on are all done by the. Net Library, because on the shoulders of giants, PowerShell is often used in practice, simple and efficient.

$RSSURL = "Http://blogs.msdn.com/powershell/rss.aspx"
$blog = [XML] (New-object System.Net.WebClient). Downloadstring ($RSSURL)

Edit, run, Debug-IDE

Windows program development, especially based on Microsoft technology, is a good thing to have a strong IDE and professional documentation for support. Whether it's Visual Studio under Windows or Mono Develop under Linux, even a language like PowerShell has a ide:windows PowerShell ISE that integrates editing and debugging. With auto-complete, instant script interaction, debugging, and even remote debugging, PowerShell scripts write "very cool and powerful." Of course the documentation is generally powerful, and the part about PowerShell in MSDN is still professional.

The disguise of the egg ache-profile

After having PowerShell, I seldom go to cmd. But as an egg-filled B-man, it's fun to disguise PowerShell as a cmd. It is not difficult to find PowerShell and CMD only in the icon, title, background color, prompt, and just start when the display text five different aspects. The icon and background color can be easily modified in the shortcut properties. and the title and the change of the prompt will need to use the profile. Profile is a script that runs automatically each time you start PowerShell. The path to this script is set in the $profile variable. Just set the $host. Ui. Rawui.windowtitle can be C:\windows\system32\cmd.exe to disguise the title as CMD. The custom prompt is naturally extremely simple for the current path in PowerShell. As for the start-up display text, as long as the/nologo parameter to hide the original version information, and then print a line of CMD in the text is good. Final effect (refer to this link for profile)

Another: Process-level work scheduling – parallel support?

==========================================================
With the rapid development of multicore processors, parallel computing has been repeatedly emphasized starting with the. NET Framework 4.0. From the newly added parallel tool classes in System.Threading to F #, a functional language that is well suited for parallelization, Microsoft has provided strong support for threading-level parallelism in a timely fashion. But for process-level work scheduling, Windows seems pretty primitive. For the simplest example, if we start 5 copy sessions to a mobile hard disk at the same time, Windows will start all copy operations at the same time. In this way, the head will repeatedly make meaningless moves (seek) between different target locations, so in the flash of the hard drive lights, a lot of time is wasted. Also, when we start several processes that are computationally large at the same time, Windows tries to "go with the process". However, in order to avoid a process to starve, the system has to switch processes frequently, so a lot of time is wasted in the preservation site, process switching, recovery site. In this way, process-level parallelism is not good enough.

Fortunately, the task scheduling management function was added to PowerShell. With a simple experiment, we can see that the PowerShell schedule for jobs is very different from the default for Windows, which generally maintains a high-speed operation with the same number of CPU cores, while other processes consume only a fraction of the CPU time. Until the previous process has finished working, there will be a new process by the end to enter the state of high speed operation. ==========================================================
Later, after more careful experimentation, I found that the original Windows built-in process scheduling scheme is a small part of the high-speed operation (on my dual-core processor is two processes Occupy 50%cpu), most low-speed follow-up (all other processes share the remaining 50%cpu). So PowerShell's work scheduling does not improve the original status of the system. At the same time, because the PowerShell scheduling system needs to occupy a small amount of memory, the initialization also takes a while. It is even 50% slower than the default schedule in the measurement. The result of the experiment was rather awkward. Why do I have to join the job in PowerShell just to invoke it asynchronously?

Not the same command line – Windows PowerShell Introduction (reprint)