Replace the batch with PowerShell!

This article mainly describes the use of PowerShell instead of batching it! This article explains the history of batch files, Windows NT and Cmd.exe, Windows Script Host, entering Windows PowerShell, why it is time to stop writing batches, and so on, the friends you need can refer to the following

PowerShell should have become a proxy for batching (Cmd.exe shell scripts), but for some reason many people are reluctant to abandon batching. This article will begin as a series of articles to help you break the habit of batching and march into PowerShell.

Before I enter these article series, I want to start with a little bit of history about batch files and why you need to write your scripts using PowerShell instead of old-style batch code.

History of batch Files

Batch file has a long history, a cp/m on a microcomputer operating system, with a command that can be submitted, which can run a series of commands in a text file line by row. It is very simple (because of the tight memory at the time) and does not support any type of conditional branching.

When MS-DOS was developed, Microsoft included a very similar batch function in its command.com command interpreter: A text file with a command, named. bat extension, and then the command interpreter would run every command in it.

In later versions of DOS, Microsoft expanded batch files in a number of ways. Added tags, goto statements, and if statements to handle branches. It is important that the "language" of the batch process is not designed. It is only derived from the cp/m can submit commands.

Windows NT and Cmd.exe

Soon to Windows NT (1993), Microsoft incorporated a console-mode application, Cmd.exe, until the day it was presented to the user in a legendary "C: Prompt". Cmd.exe is a superset of the old MS-dos on Command.com, and even uses many of the same commands. command is similar, it is designed backwards compatible to ensure that users are able to run batch files on older MS-DOS. The Cmd.exe can also run with a. Bat extension "batch file".

The similarity between Cmd.exe and Command.com is its backward compatibility with. bat files, and Microsoft has just begun to select the Cmd.exe icon ("MS-DOS" logo) that has caused users to puzzle for years. Even today we are in some community of forums and will see some questions about "what to do with Dos", in fact this is a DOS bird thing.

Cmd.exe has more features than Command.com, which is the extension of batch files. This includes the iteration of for/f, which simply invokes the subroutine with the call command, specifying the environment (Setlocal and endlocal). While these enhancements make batching "language" more practical, it still has a number of flaws, which makes writing a simple batch process a headache.

Windows Script Host

Starting with Windows 2000 (1999), Microsoft enhanced its scripting capabilities by introducing Windows Script Host Two real, built-in, programmable languages (VBScript and JScript Microsoft version low JavaScript). WSH scripts rely on COM objects to interact between the operating system and the application. Although WSH is extremely useful and powerful, it is limited by the need to install the required COM objects on the machine and does not provide a command-line interface.

Enter Windows PowerShell

Batch and WSH scripts do not provide consistency because they are two separate enhancement tools that have different user interfaces (batch and WSH scripts are not the same). Aware of this, Microsoft released the first version of Windows PowerShell in 2006, ending the Battle of the nations and unified the Windows Script. PowerShell is based on the. NET Framework, provides a command line, and manages the interface of the Windows operating system.

Now that we have Windows PowerShell, there's no need to write legacy batch files (Cmd.exe shell scripts). Looking ahead, you should focus your energies on learning PowerShell, mainly because Microsoft has positioned PowerShell as the default tool for Windows operating system automation and enterprise application management.

Why is it time to stop writing batches?

Here are five reasons why you should stop writing batch files and turn to PowerShell scripts.

1.PowerShell is the future, is the benchmark. Microsoft has positioned PowerShell as the default tool for Windows operating systems and Microsoft enterprise Application Management. Many third-party vendors also provide a PowerShell class library to manage their products.
2. Batch processing is obscure, it has many flaws. I used to go to some of the scripting Web sites, and I can't count how many times I've asked you why the environment variable is not right after it's been expanded. There is really no need to put yourself on the cmd.exe. There are too many restrictions on batching, so put yourself in the bosom of PowerShell!
3.PowerShell is support for batching and command lines, and turning to PowerShell does not mean discarding batches, old-fashioned batch files can still run well on PowerShell, and command-line tools are still perfectly compatible with PowerShell.
4.PowerShell is a true scripting language, and you may not have tasted the benefits of PowerShell, especially if you are trying to experience some complex logic that is significantly simpler in PowerShell than CMD.exe. Many times, a row of PowerShell command lines can replace hundreds of batches of code.
5.PowerShell uses objects, unlike Cmd.exe and other text-based shells that can only use the text's command output. PowerShell, on the other hand, uses. NET objects, and those that have been tricky in batches (such as date-time parsing) have become surprisingly simple in PowerShell.

Throw the batch.

Cmd.exe will not perish in the short term, but there is no reason why we should take pains in this old-fashioned batch language, throw it down, and use PowerShell instead of it!

Replace the batch with PowerShell!