It is a common notion that the more you use the Terminal (as opposed to the GUI), the more efficient you are. Typing out commands is much easier and faster than clicking around the screen. However, to someone who has just begun using the Terminal, it may not be so. Over time, as administrators grow more and more comfortable with the Terminal, they learn to configure it for speed and efficiency, much like training a horse. Further, most efficient administrators like automating several parts of their workflow—customizing .bashrc and Vim scripts are examples of this. In this chapter, we will familiarize ourselves with the different consoles and tools that work with PowerShell, and will also look at a few simple recipes that would help customize our workspace, so that we can be more efficient.

Scripting can happen on the console itself, with Vim. It is also possible to use other editors, such as Gedit or even Atom, to write PowerShell scripts. It is, however, recommended to use Microsoft's open source code editor, called Visual Studio Code (or vscode). In this recipe, we will look at installing Visual Studio Code and configuring it to work with PowerShell.

We will look at the steps to install vscode on Ubuntu. Today, most repositories contain Visual Studio Code. You can check in the software store of your distribution to install vscode. If not, the easiest way to install vscode is to download the .deb (or the .rpm package if you are on CentOS) and run it to install...

Perhaps nothing contributes to efficiency like configurability. Configuring a system is a way of tuning it to your taste. You are the only one who knows what works best for you. Therefore, the more configurable a system is, the better it can be tweaked to your preference. Automatic variables in PowerShell are one of the first steps to customization in PowerShell (profiles are the other; we shall look into them shortly). In this recipe, we will list out all of the automatic variables and configure some of them to our requirements.

Read the Listing the various providers in PowerShell recipe of Chapter 1, Introducing PowerShell Core, to learn how to use the various providers in PowerShell...

In the previous recipe, we took a look at the existing variables. In this recipe, we will change the value of one of the variables to control the behavior of PowerShell. Again, remember that the change in the value is ephemeral; the values would be reset once the PowerShell process is restarted.

Read the previous recipe to understand the automatic variables that come predefined. Also, start Visual Studio Code. Perform the following steps to start Visual Studio Code:

1. Open applications (I use the GNOME desktop environment, which shows all applications with Super + A).
2. Type in code.
3. Press Ctrl + ` to launch the Terminal.
4. Click on New File on the welcome screen (or press Ctrl...

As we saw in the previous recipes, these changes are ephemeral; they remain as long as the session is active. There might be situations where administrators might require running a few commands or loading modules to enable them to work faster. For instance, I tend to load a series of modules that help me manage Microsoft Exchange, Active Directory, VMware vSphere infrastructure, Citrix XenApp, Microsoft System Center, and other environments using PowerShell.

All of these products require different ways of loading the modules, snap-ins, and scripts, and many of them require a certain configuration every time you load the modules (such as connecting to VM servers with administrator credentials). These can be done using the PowerShell profile.

In the previous recipe, we customized the error action preference using the profile. We used an already-demonstrated command to show that commands that can be run on the PowerShell console can be added to the profile as well, and this was a way to automate running a certain set of commands which could be used to increase productivity.

Now, we will take the next step and customize our console prompt. The options are theoretically endless; this recipe is just another demonstration of how flexible PowerShell is.

You need Visual Studio Code for this recipe. If you did not follow along with the last recipe, follow the steps in the Getting ready section of the last recipe to create...

During the process of learning to use Bash or sh, we learn to use the redirection operators, such as <, >, and >>. PowerShell works on redirection as well. However, the implementation of redirection is different in PowerShell.

Redirection in PowerShell mainly relies on streams, which are covered in a different chapter. For this recipe, we stick with the default stream, which is Success. This recipe covers different, simple redirections to help with basic administration.

Before we begin, let us understand that PowerShell is very different from Bash in terms of redirection, although it packs some minor similarities; similarities enough to make you not go away, but rather appreciate the flexibility of the object model and the uniformity of use.

In Chapter 1, Introducing PowerShell Core, we saw how native Linux commands were not convenience aliases in PowerShell on Linux, but the commands themselves. In this recipe, we will demonstrate using Linux commands at the PowerShell prompt. Remember, we used a Bash Terminal to run the ls -l and awk commands to list the contents of a directory and separate the columns in the output in the recipe, Comparing the outputs of Bash and PowerShell in Chapter 1, Introducing PowerShell Core. We will perform the same operation on the home directory, from within PowerShell, without using any of the PowerShell cmdlets.

It is recommended that you have a Windows PC with PowerShell...

Most of our scripting and administration is going to revolve around running cmdlets and chaining them. In some situations, we run a cmdlet expecting it to work a certain way, only to find out that the cmdlet threw an error, or worse, did something undesirable.

The key to getting cmdlets to do what we want them to do is to eliminate ambiguity. In this recipe, we will learn to construct commands contextually and effectively.

Read the Help section of Chapter 1, Introducing PowerShell Core. Let us understand the notifications used in the help information that Get-Help shows.

While this may not be an exhaustive guide to using the help information, it should cover most of your daily...

Commands have been made to be short, historically. However, the situation turned into a dilemma over time, since shorter commands meant that they had to be remembered and longer commands meant more keystrokes.

PowerShell has long commands; however, it deals with them in two ways:

• Aliases, which tend to be shorter
• Tab completion, which require more keystrokes than aliases, but doesn't require remembering much

The first way necessitates using our memory to recall command names as required. The second, on the other hand, solves the keystroke issue efficiently.

Bash users are used to getting a list of matches laid out in a nice tabular format when the Tab key matches more than one string in the context. On the other hand, the matches cycle at the cursor in Windows (which most Bash users find weird).

Be that as it may, tab completion is...

Find all of the commands that take in ComputerName as a parameter, with minimal keystrokes...

PowerShell scripts are nothing but a series of PowerShell cmdlets, each in a line of a ps1 file. These instructions are executed one after the other, similar to the good old shell script. Using Visual Studio Code makes running PowerShell scripts simpler, in that you simply have to run the script to make the script work its magic.

However, running PowerShell scripts on Visual Studio Code is not the usual way of automation for obvious reasons. Also, there are many ways to run a PowerShell script. We shall look at a very simple way of running the script in this recipe; as we progress in this book, we will also add more features to our scripts and, further, will package them into modules for future use.

In the previous recipe, we saw how to call PowerShell scripts from outside of the IDE. We gave PowerShell the path and explicitly mentioned that we would like it to run the script, by using a call operator.

This way is ideal if you would just like the script to perform its task and not leave anything behind, such as variable values. However, there are situations where we would like to run a script and, say, retain values of the variables we declared and assigned in them or use the functions we declared in them.

In such situations where we would like the functions, variables, and even aliases retained in the current session, we use dot-sourcing.

If you deleted the file after...

So far we have learned how to call cmdlets from the console, run scripts at the IDE, and call scripts in two modes. In this very short recipe, we shall learn how to call a PowerShell cmdlet from outside of PowerShell.

1. Open a Terminal window.
2. At the prompt, type the following:

$ pwsh -h

3. Read the syntax for the command.

4. At the prompt, type the following:

$ pwsh -c Get-ChildItem

5. Let us now run the hello-world.ps1 script:

$ pwsh -f ./Documents/code/github/powershell/chapter-3/hello-world.ps1

Often, there are situations in which you perform a series of tasks on your PowerShell console and, after quite some trial and error, come across a solution. And then you wish you had recorded everything you did on the console. You could still copy content from the console, so you try to scroll up. But you can only go so far. Your command history (a little like Bash history) can help you, but sometimes, that feels limited as well.

A few months ago, we were troubleshooting a sync issue between two of their software update distribution systems, which were supposed to work in sync. After some of us were done beating around the GUI, we decided to pick PowerShell to fix the issue. We ran a series of commands and, after a few hours of fighting with the systems, they yielded and we were back up and running.

Our managers asked for all...