Cmd or Powershell? Which one to use?

Command line tools allow us to perform a multitude of operations that range from obtaining a simple information to executing maneuvers that involve massive changes. Tasks that if we were to perform through the graphical interface, in addition to taking a million times longer depending on the volume, we would still have the feeling of seeing time being wasted on something that could suddenly have been automated. In that sense, the value of command-line tools is really unquestionable.

Read more:

The best Windows Server courses of 2021
How to avoid password sharing on vacation via Powershell
WSL - Linux on Windows
Find out what features you will lose when you migrate to Windows 11
How to use the PowerShell Help command

cmd or powershell.exe?

On one side we have our beloved command prompt, Cmd, the standard Windows command interpreter. On the other we have powershell.exe, the console through which we interact with Powershell technology.

Since 2006, in its first release, Windows Powershell has been improved, thousands of cmdlets have been added or updated, and the way we administrators work has been heavily influenced by this evolution. Windows Server 2012, for example, which brought version 3 with it, could already be practically all managed with just Windows Powershell.

But the question remains, why choose Powershell over command prompt?
One could say: – Ah, you can do a lot more with Powershell.

Will be?

We were able to manipulate files and folders with Powershell and various other file system contexts. With the prompt too.

It is possible to perform operations on the windows registry with Powershell. With the prompt too.

With Powershell we can perform advanced tasks involving WMI classes and COM objects. With the prompt too.

With Powershell we can automate a series of tasks through scripts including decision structures and loops of repetition. With the prompt too.

Of course, the examples above are by no means exhaustive, but we can have a view that the two tools show themselves to be strong candidates when it comes to performing administrative operations.

Someone else might say: – Sure, the two tools have their value, but you can't even compare how intuitive, user-friendly and practical Windows Powershell is compared to the prompt.

Personally I agree. Windows Powershell is much more user-friendly, intuitive and practical, and maybe just these predicates would be enough when choosing it over another. However, the chasm that separates the two tools is even greater and deeper.

There is a huge range of command line tools out there, but let's stick with these two.

Appearances can be deceiving!

Take a test. Start both tools and run the ipconfig command on each of them.

No biggie, do you agree? Aside from visual issues like color and font, the two command line tools showed the result of running the ipconfig utility.

If we could get an X-ray, an MRI or something of that nature, what would we see on each screen? We would see the big reason the Powershell exists: Objects, objects and objects.

Cmd, like so many others, is a text-based command-line interface and doesn't deliver us anything but text. Our friend Powershell, on the other hand, takes advantage of the .NET object model and so instead of text it hands us objects.

We're not going to get into the subject of object-oriented programming here, but if it's of interest to you, it's well worth your while to get this kind of knowledge.

If this subject is unfamiliar to you, just keep in mind that an object in Windows Powershell is mainly composed of two things: Properties and Methods. Properties is what qualifies, characterizes an object. Methods are actions that the object performs or can perform on the object.

Imagine a car. A car can have the properties make, model, year of manufacture, chassis number, etc. The methods could be on, off, fueling, stopping, parking, and so on.

When we said that Cmd delivers text to us, it is exactly that. Strings, string of characters. As we've already mentioned, this feature is not exclusive to the prompt. Chat with Linux administrators. One of the reasons why grep, sed, awk and company utilities are part of the daily lives of these people is exactly that. Handle text-based output.

Powershell in turn delivers objects to us. When we run, for example, the Get-Service cmdlet, what is displayed is not just text formatted with service information. What is displayed on the screen are the services themselves. Remember the X-ray story? There is some truth to this. In fact, we can see what's behind the output generated by a command executed in powershell.

Get Member

Remember what we talked about earlier about properties and methods? Well, through the Get-Member cmdlet we can see which Properties and Methods an object is composed of, that is, we can know which are the members of the object in question.

To illustrate the representation of objects, let's take as an example the Windows Intelligent Transfer Service – BITS.

Get-Service BITS

Now let's see who the members of a Windows service are, that is, what the properties and methods are. There are other members besides properties and methods, but these two are the most relevant.

Get-Service BITS | Get Member

Here we have some very interesting information. First, we learn that our object is of type ServiceController and has some properties and methods.

Activating Properties

As you may have already noticed, properties are the names of the columns displayed after the cmdlet runs. In the case of Get-Service, the columns (properties) shown by default are Status, Name and DisplayName. But that's when we started to enjoy an object-based shell. We can select the properties we want without having to manipulate text. Let's say we want to show properties:

• DisplayName
• CanPauseAndContinue
• CanStop
• Status

Get-Service BITS | Select-Object DisplayName, CanPauseAndContinue, CanStop, Status

It is also possible to select a property with the operator “.”

(Get-Service BITS).Status

triggering methods

Methods are actions. Fortunately, we don't have to resort to the methods very often and there's a reason for that. For many of the methods the object has, another cmdlet may already exist to perform the desired action. For example, let's stop the BITS service via the Stop() method

(Get-Service BITS).Stop()

Method invoked, service stopped. But as we said there might be an equivalent cmdlet, in that case instead of calling the Stop() method we could have used the Stop-Service cmdlet.

Since the service has been stopped, let's start it again, but instead of using the Start() method, let's use the Start-Service cmdlet.

Start-Service BITS

ipconfig

When we started the article, we used the ipconfig utility to do the comparison and then moved on to using the Get-Service cmdlet. It was on purpose.

Unlike Get-Service, ipconfig is not a powershell command. It is a utility present in the operating system that we can run through the console powershell.exe as we would do with Cmd or any other command interpreter. While Get-Service is a cmdlet, ipconfig is classified as an application.

Get-Command ipconfig,Get-Service | ft -AutoSize

It means to say that ipconfig has no obligation to bring structured data in the same way as Get-Service. But, despite not showing us an output that refers to objects, still the result of ipconfig is an object. In this case, an object of type String.

ipconfig | Get Member

Being an object of type string, we can treat it as such. Strings have many methods available and we will employ a few.

Without much effort, we can move all ipconfig output to uppercase with the ToUpper() method:

(ipconfig).ToUpper()

We can replace the interface name with the Replace() method.

(ipconfig).Replace("INTERNAL","InfraTips")

Of course, manipulating ipconfig output might not be exactly helpful, but it's just one example of how we can take advantage of the Windows Powershell object model even when we're dealing with unstructured output. We take ipconfig as an example, but it could be any other utility.

Conclusion

At this point in your reading you should be exhausted from seeing the words: Objects, Properties and Methods. But believe me, having this understanding makes all the difference from running a single cmdlet to developing complex scripts and functions.

• It is thanks to the power of objects that we can concatenate several cmdlets into a single line through the pipeline mechanism.
• Every object is of a type.
• Some methods already have an equivalent cmdlet.
• Not everything that runs in powershell.exe is a powershell command.
• Make Get-Member your work companion!

I hope that you enjoyed!

Was this article helpful?

To maintain a quality standard for you, we have invested in a great hosting plan, Paid CDN, Website Optimization Plugins, etc ...

Help us to keep the project active! 

Follow the news in real time. Follow our Instagram profile..

Fernando dos Santos
Infrastructure Analyst focused on M365 and Windows Powershell.
en_USEnglish

UP TO 90% DISCOUNT

TAKE OFF YOUR CAREER !!

Do you want to upgrade your career? 

Invest in yourself and get ahead! Get that dream job in 2022!