Scripting

Shell scripts are still a hotly disputed Linux topic: Some users love the ability to bundle commands together in a file and then execute them. Others see the work of the devil in shell scripts and argue that any shell script longer than ten lines should be written in a scripting language such as Perl or Python. Those who advocate shell scripts can be happy with PowerShell, which offers the ability to execute commands via a PowerShell script. The principle works the same as with typical Linux shells. It is important that the script file ends with .ps1.

As with Bash, you string together the cmdlets you want to call in PowerShell scripts. PowerShell scripts can also be equipped with conditions, so such as If, Elseif, and Else (Figure 3).

Figure 3: PowerShell supports conditional expressions.

You will also find an option to store your own functions in the form of modules: The example of Apache [5], which the PowerShell developers list in their GitHub directory, explains this feature well. As admin, you can define functions with the keyword Function in a file with a name that ends with .psm1. As is customary with other shells, functions can have parameters. The module definition then loads each shell script with the Import-Module cmdlet; your own definitions are already available within the shell script.

An Alternative?

It is probably beyond dispute that Microsoft's has great ambitions for open source, since they have invested substantial resources into making an open source product from PowerShell. Yet PowerShell for Linux currently exists as something more like a proof of concept.

In the GitHub directory of PowerShell, Microsoft maintains a list of problems that currently rattle PowerShell on Linux. On the one hand, publicly tracking the problems is laudable, since it shows a commitment to openness. On the other hand, the list reads like a message from the house of horrors, with some basic functions still defective at the time of this article went to press.

For example, admins are accustomed to using wildcards from Linux shells so they can select several files dynamically on the command line (* for multiple characters or ? for one character). Wildcards work on PowerShell, but only for cmdlets. If you call a native Linux binary from PowerShell and pass a wildcard, you will receive an error because PowerShell does not automatically replace the wildcard character. (Figure 4).

Figure 4: The dir and ls commands call up different programs, although globbing with wildcards does not work with ls.

Calling native Linux binaries on PowerShell has yet more unpleasant side effects: The return value of cmdlets is always an object. PowerShell relies on objects to facilitate features such as forwarding the output of a program to other programs as input. Native Linux programs produce the classic return values and no objects, on the other hand, meaning that the piping does not work here.

The fact that PowerShell does not distinguish between upper- and lowercase by design is at least as serious. In particular, this affects finished PowerShell scripts from the web: If you download a finished script for a particular task, you will have to hope that its author uses exactly the same name the current module has in the filesystem when loading external modules, for instance. In a Linux environment, you would simply receive an error message instead.

The topic of case sensitivity is also a problem for Windows admins arriving at Linux from PowerShell. Upon completing the input with the [Tab] key, PowerShell displays the relevant program on Windows, no matter whether it is written with matching upper- and lowercase. If you are on Linux, however, and enter MK in the belief that it will auto-complete to mkdir, you will simply get another error message.

To top it all, some stumbling blocks will arise from fondly-held conventions if Linux admins use PowerShell, or Windows PowerShell users use Linux. It is possible to stop or start programs via PowerShell on Windows, for instance, but the commands necessary for this do not work on Linux.

If you are not scared off by these teething troubles and attempt your first steps with PowerShell, Microsoft offers very generous help. Along with PowerShell for Linux, the giant from Redmond has provided complete examples of new cmdlets and demonstrated how you can use scripting languages (such as Python) in a sensible way with PowerShell. If you are interested, you can find the full sample archive online [6].

Conclusion

At the time of this test, PowerShell for Linux is still a construction site, which will hardly put experienced Bash admins at ease. However, Microsoft is still calling PowerShell for Linux an alpha version, and public development (along with bug searching) has only been underway for a few months.

Much more important than the state of the product is the significance of PowerShell for Linux as a signal that Microsoft no long views Linux as a nemesis, but as a competitor, and even a genuine partner for possible cooperation. Microsoft CEO Satya Nadella was photographed a few months ago with a PowerPoint slide that read "Microsoft Loves Linux," causing some amusement on the scene. The release of Linux PowerShell and the work that Microsoft has been putting into in the product prove that those were not empty words.

PowerShell for Linux is only at the beginning of its development. If Microsoft maintains its current pace, PowerShell could become a serious competitor for established Linux shells within the foreseeable future.