Use PowerShell instead of batch processing! _powershell

PowerShell should have become a good substitute for batch processing (Cmd.exe shell script), but for some reason many people are not very willing to abandon the batch process. This article will be the beginning of a series of articles to help you break the habit of batch processing and march towards PowerShell.

Before I go into these articles series, I'd like to start with a bit about the history of batch files and why you need to use PowerShell to write your scripts instead of old-style batch code.

History of batch Files

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

When developing MS-DOS, Microsoft also included a very similar batch function in its command.com command interpreter: Put the command in a text file, name the extension of. bat, and then the command interpreter would run every command in it.

In later DOS versions, Microsoft extended batch files in a variety of ways. Added tags, goto statements, and if statements to handle branches. It is important that the batch "language" is not designed. It was just born out of cp/m to submit an order.

Windows NT and Cmd.exe

It's very soon. Windows NT (1993), Microsoft incorporates a console-mode application, Cmd.exe, until this day it also presents a legendary "C: Prompt" to the user. Cmd.exe is a superset of Command.com on the old MS-DOS, and even uses many of the same commands. command, it is designed to be backward compatible to ensure that users can run old MS-DOS batch files. Cmd.exe can also run with the. Bat extension "batch file."

The similarity between Cmd.exe and Command.com is its backward compatibility with. bat files, and Microsoft's newly chosen Cmd.exe icon (the "MS-DOS" logo) has caused users to become confused for years. Even today we are in some forum community, we will see some questions "how dos what", in fact, this is a DOS bird thing.

Cmd.exe has more features than Command.com, and the corresponding extension of batch files. This includes for/f iterations, simple use of the call command to invoke subroutines, and the designation of the Environment (Setlocal and endlocal). While these enhancements make the batch "language" more practical, it still has a number of flaws, making it a headache to write a simple batch process.

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 version of Microsoft Low JavaScript). The WSH script relies on COM objects to interact between the operating system and the application. Although WSH is extremely practical and powerful, it is constrained 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 enhancements that have different user interfaces (batch and WSH scripts are not the same thing). Microsoft realised this, and in 2006 it released the first version of Windows PowerShell, ending the infighting and unified the Windows Script. PowerShell is based on the. NET framework, providing a command line and an interface for managing Windows operating systems.

Now that we have Windows PowerShell, there is no need to write legacy batch files (Cmd.exe shell scripts). Looking to the future, 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 batch processing?

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, and it has many flaws. I used to go to some of the scripts to ask the site, I can not count how many times I asked, such as why the environment variable expansion is not correct, why the command after the operation is not correct. There's really no need to put yourself on the cmd.exe. The limit of batch processing is too much, put into the bosom of PowerShell!
3.PowerShell is support batch and command line, turn to PowerShell is not to say discard batch, old batch file still can run well on PowerShell, command line tool also still can be perfect compatible to run on PowerShell.
4.PowerShell is the real scripting language, you may not have tasted PowerShell, especially when you try to experience some complex logic, which is much simpler in PowerShell than CMD.exe. Many times, a line 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 command output of text. On the other hand, PowerShell is using. NET objects, which have become surprisingly simple in the PowerShell of previously intractable problems in batch processing, such as date-time parsing.

Drop the batch.

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