Who’s afraid of the big bad PowerShell?
So… you are maintaining a distributed Windows or multi-platform environment, or automating a repetitive task, or creating a set of tools for yourself and colleagues. When it comes to automation the tendency is to run off in directions of Python or C# or other languages or tools. And when someone mentions the name PowerShell people run screaming for the hills “Anything but POWERSHELLLLLLL…….”
Why?
PowerShell is usually seen as some monstrous scripting language comprised of shell commands made up of strange combinations of words not usually associated with scripting, easy learning or fluid coding. Just a quick squint at the never-ending list of CMDlets available in a standard PowerShell setup is enough to send a fair few people in the other direction.
Where most platforms use recognized commands like “cd” or “ls” or “dir”, PowerShell makes use of Verb-Noun pairs that seem intimidating at first. And PowerShell’s use of full words to name parameters make PowerShell commands look long an unwieldy (FYI… lookup PowerShell Splatting…!!!). This, together with the fact that PowerShell has (up till recently) been limited to the Windows ecosystem, generally leads non-Windows admins towards other more ubiquitous, well-known tools.
There may be fears regarding security of PowerShell, or the highly unlikable PowerShell ISE as a development platform, or views that simply label PowerShell as a particularly difficult or convoluted shell language.
I will go through why these fears are baseless, and why learning to use PowerShell in the administration of all your Windows and non-Windows environments alike should be made a priority in your organization.
PowerShell is not a scripting language… only
I know… you’re thinking “this guy has lost it”. Well you may be right, but that is a topic for an entirely separate post…
PowerShell is primarily a real-time interactive administration tool that allows you to administrate your systems without the need for a cumbersome, slow GUI, and to automate repetitive tasks. It comes with a built-in command-line shell and a scripting language in one package.
This includes a huge native lexicon of useful CMDlets that will allow you to interact with your system without the need to create the tools yourself or install third-party extensions/modules. From managing Windows services, to sending emails, to making REST API calls, to creating a mobile device policy and enforcing it all in one line of code, and far far more. The list of built-in native tools is staggering, reducing your external dependencies and coding overhead. No need for lists of imports at the top of your script to perform basic administration tasks. That having been said, there is a huge ecosystem of third-party modules you can use to boost your PowerShell setup, and writing your own is a piece of pie. (not cake… we prefer pie)
The addition of PowerShell modules available for most Cloud providers (AWS, GCP, Azure) makes administration of cloud-based infra a breeze, automating your most common maintenance tasks world-wide without the need to work through a time-consuming console UI.
It has built-in security, so you can be assured that non-secure scripts or unauthorized users are unable to ruin your day, by accident or otherwise. And it works seamlessly through the network with distributed Windows and non-Windows systems alike (read on if your eyebrow rose a bit). This means you can interact with multiple, distributed systems simultaneously, in parallel, both in real-time and via scripting/automation, be it simple or complex.
There are even cases where PowerShell has vast advantages over Windows GUI’s, where some features and options are only available via PowerShell, forcing power-users towards the command-line and away from those cumbersome UI’s.
A CMDlet by any other name
- True, to change directory in PowerShell you make use of the CMDlet Set-Location.
- True, to list the contents of a directory you use Get-ChildItem.
- True, to output something to the shell you use Write-Host.
- True, to create a new directory you use New-Item -ItemType Directory
“Booooo” you may say… “too convoluted…”
Credit: MemGenerator.net
Well hold on a bit… you may be surprised to learn that the good people who wrote PowerShell were thinking of you all along. They were taking into consideration the admins who are used to other systems like Linux/Unix or other languages like the original Windows Command prompt (CMD) or Bash. So for very many of the most used CMDlets, the peeps over in the PowerShell department added aliases, meaning…:
- You can still use cd to change directory
- You can still use dir or ls to list the contents of a directory
- You can still use echo to write to the shell
- You can still use mkdir to create a new directory
- You can even use commands like man to get help
Additionally, any of your native Windows commands will also work. Things like ping, ipconfig, etc…. and the list goes on and on. You can even set your own aliases for any command you want, existing or self-written.
It is also easy as that pie we mentioned earlier to find out all you want to know about a specific PowerShell command or object by using some simple tricks.
- As mentioned above, use get-help <command>, or man <command>, or help <command> to get an in depth look at how to use the command you need
- Use $Object | Get-Member or $Object | gm to find out all you want to know about the object you are attempting to use or manipulate
- Use <ModuleName> | Get-Command or <ModuleName> | gc to get a list of all available CMDlets or functions in any PowerShell module
So to get started, just open the PowerShell prompt and start typing commands you already know. You may be surprised how many of them work just as you would expect them to.
DIY Modules and much, much more
PowerShell is a fully Object-Oriented, functional language when used to script. This allows you to easily create reusable classes, functions, or even entire modules.
Modules can be compiled C# or simply a group of your own functions in standard PowerShell language saved in an uncompiled script file with a psm1 file extension. So to get started creating your own classes, functions or modules just write a PowerShell script and change the extension… that simple
Developing PowerShell automation has also improved recently with the advent of Microsoft’s Visual Studio Code which, together with the PowerShell extension, has officially replaced the unattractive and outdated PowerShell ISE (being deprecated as we speak). Being a light-weight, fully featured and robust IDE with a multitude of available extensions for just about any language, tool or personalization you can think of, VSCode has taken the development of PowerShell scripts and modules to a new level
Add to all this
- The fully object-oriented nature of PowerShell and its ability to run C# code natively
- The wealth of third party modules that already exist together with a fully featured package management as of PowerShell 5.1
- Full access to the entire .NET ecosystem (PowerShell is actually a built-in .NET dll)
and it becomes clear that grouping your most commonly used tools and most frequent, repetitive and time-consuming tasks into a PowerShell module can
- Decrease time needed to develop new automation tools and scripts
- Improve ease of system-wide administration, automation and auditing
- Make your automation code far more efficient and readable, and…
- Improve security and system/tool robustness… among other advantages…
The Shell of the Future
“But wait… I am not on Windows”
“I don’t like PowerShell because it locks me into a Windows environment”
“If only I could use it on all my non-Windows systems”
Stop! No need to continue. These statements are now outdated. Since its first release in June 2016, .NET Core has come a long way as Windows’ breach into the Open Source world. Along with it comes PowerShell Core 6.1 (latest version as of this writing) with full support for use on all non-Windows systems.
True, you may argue that it will be difficult to replace existing scripting on Linux (eg. bash) with PowerShell. Or you may say “Well Python is far more ubiquitous already”. But Python is not really a shell language although it can be used as such if done correctly. And bash is not really a great object oriented scripting language, although it can also be used in this way if done correctly.
PowerShell on the other hand is both a shell and a scripting language by definition, which is fully object oriented, without overly intricate syntaxes, and easily-written, plain-language, non-compiled code, so it really does cover all the necessary bases.
It will be interesting to see how much PowerShell Core will catch on, but it is not crazy to foresee a wealth of related tools being added to the Core ecosystem in the not too distant future.
Let’s talk bottom line
Whether you are just looking to automate some repetitive or time-consuming tasks, or you are a power user wanting to automate your private environment, or a sys-admin, IT or production engineer responsible for large-scale distributed systems, it is definitely worth your while to invest time in learning PowerShell. It may not replace all your other tools, but it will definitely make a worthwhile addition to your repertoire and may even surprise you by becoming one of your favorites….
