Windows PowerShell was designed with the following thought in mind: How could a technology be designed that combines the power of C# with the simplicity of a scripting language or shell? Therefore, PowerShell is architecturally a composition of types, especially those from the .NET framework. .NET access was necessary because the API of Microsoft's server products changed. The use of Visual Studio and high-level languages for administrative purposes was something that could no longer be reasonably expected. The result was the multilayer architecture of PowerShell.

The commands form the top of a pyramid, with a strong dependency on the underlying type library. This relationship is clear from the installation prerequisites for the different PowerShell versions (Table 1). The mutual dependencies between the installed .NET libraries, system components, and PowerShell make it impossible to use Windows PowerShell outside of Windows. The get-process command, for example, is based on the System.Diagnostics.Process type. However, if these classes are only available for Windows operating systems, the command pyramid lacks a basis. This changes with the new concept of .NET Core.

All New in .NET Core

One disadvantage of the classic .NET architecture always has been the distribution of apps. Developers need an existing and suitable .NET framework version on the target system, and changes have to be adapted to the run-time environment. In principle, the environment determines the characteristics of the applications. The fixation on Windows is another limitation.

.NET Core looks to overcome these limitations through a modular structure. A subset of the .NET framework and the Common Language Runtime has been outsourced into a separate package. The portability of .NET Core and apps hosted within it on different processor architectures and operating systems is the central feature of Microsoft's modern class library, making it possible to scale applications from data centers to mobile devices.

This new variant of .NET, currently in versions 1 and 2, is open source and available for Linux and Mac OS. Because of the close relationship between the class base and PowerShell, these changes have a direct effect on PowerShell. PowerShell Core (PSCore) can be used on Linux and Windows and distributed as an application. As an administrative tool, PSCore cannot be removed completely from the operating system.

One example is Windows Management Instrumentation (WMI). Since Windows NT, the popular class library has offered administrators access to almost all hardware and software objects for the administration of servers and clients. However, the get-WmiObject command immediately results in an error message under Linux, because WMI is not available under Linux. Therefore, there are no classes on which the commands can be based. The same also applies to COM/DCOM objects.

Installing PSCore

PSCore sources and packages, along with short manuals, are available for various operating systems on GitHub [1]. For Windows, an MSI package is available for download, and the installation routine gives you the choice of storage location. On Linux systems, the DEB package installs PSCore in the /opt/microsoft/powershell/<version number>/ directory.

The sources for developers are also found on the GitHub page. After starting the pwsh interpreter, I recommend selecting Edit | Profile Preferences from the menu, where you can set color and font. Further settings can be made under Edit | Profiles .

The three most important PowerShell commands are available for an initial test: Get-Command is used to explore the commands available in the console, Get-Help documents the use of these commands and retrieves explanations of concepts and constructs, and Get-Member displays the type from which a command is derived. To illustrate the differences between conventional PowerShell and PSCore, a Linux variant is recommended as the operating system.

PowerShell on Linux

PSCore retains the intuitive verb-noun command structure. Because the nouns are the administrative targets, listing the nouns on each system and under each host is the first way to get a better overview:

> Get-Command | Select-Object -Property noun -Unique | Sort-Object -Property noun | Format-Wide -Column 5

When looking through the output list, you will notice that many familiar objects are missing, including service and eventlog . However, the Windows variant of PowerShell 6 still includes options for managing services and the WinNT event log.

A gap in the command scope between PowerShell 5.1 and PSCore continues from PSCore for Windows to PSCore for Linux. A look at the Management core module, for example, reveals various differences, as summarized in Table 2.

Of course, modules, commands, and drives from Windows structures or protocols are not supported either. The Active Directory (AD) module, the AD and WSMan drives, and, for example, the Add-Computer command are included. As far as the quality of interactive help on the console is concerned, both commands and concepts or constructs can be analyzed as usual under Windows:

> Get-help get-process -Examples;
> Get-help about_if;
> Get-help about_Regular_Expressions;

The final test is .NET Core. The get-Process | get-Member statement produces the same result under Linux as under Windows. Thus, the return value is definitely proof for the partial porting of the .NET framework to Linux. The three automatic variables $IsLinux, $isWindows, and $IsMacOs of Boolean type are new and allow the host operating system to be queried to implement OS switches for cross-platform scripts. The second host with a development environment familiar in the traditional PowerShell, PowerShell ISE, is missing in the PSCore variant. However, with Visual Studio Code, a very good development environment is also available for Linux (Figure 1).

Figure 1: PowerShell ISE is not available on Linux, but development environments like Visual Studio Code work well.

Since version 5 of PowerShell, the PsReadline module on the console has provided help with syntax completion and colored highlighting to distinguish between commands, strings, and variables. Commands, paths, and parameters can be completed with the Tab key. Pressing the Tab key several times in the Windows shell provides a continuous list of suggestions with several valid expansions. Under Linux, the module is also integrated but behaves differently: The Tab key immediately generates all potential expansions; syntax completion is not performed until the results become unique. This behavior is controlled with:

> Set-PsReadLineOption -EditMode <Windows/Emacs>

The default value under Linux is Emacs.