Differences in Unix/PowerShell Command Pipelines
Hello again! It’s me, your friendly neighborhood PowerShell user with a little deep-dive into the differences in pipelining between traditional *nix shells like Zsh or the Bourne-Again Shell, and PowerShell.
We’ll cover some little examples of pipelines in Zsh and PowerShell, demonstrating what each shell’s strengths and weaknesses are, and close with a neat little example showing differences in the order of operations when using I/O redirection.
For this example, I’m going to show how the ‘git status’ command’s “--porcelain” flag can be useful for documenting changes made to a version control repository. The porcelain flag provides the output of the command in a simplified format designed to be used for scripting.
I created an example directory structure containing text and markdown files, with two subdirectories. Here is the structure of the example directory, shown using the tree command.
Next, we can see what the output of the standard status command is. The extra information provided is very helpful to a human user, but this output is not formatted in a way that can be easily parsed.
Below, we can see the output of the previous status command shown in a scriptable format thanks to the “--porcelain” flag. Nifty! What sorts of things can we do with this? Using some simple Unix commands we can write a command that identifies when new markdown files have been added, stores their names in a document. This could be useful for somebody maintaining documentation, for example!
In Figure 3, we can see that new files that have been added but not committed are displayed on a line beginning with ‘A ‘. By using the grep command, we can filter the output of ‘git status’ to only pass lines beginning with ‘A ‘ through to the next command. Sed can be used to remove that pattern from the line, before redirecting the output to a file.
The next image (Figure 4) shows a command adding new files to the source control repository, checking the status, and redirecting the names of any new files added into a text file. We use the cat command to print the contents of a file, and we can see that our pipeline worked correctly.
Powershell is designed with automation in mind, and its implementation differs from the shells you might be you used to as a result of this. Unlike in other shells like Bash or Zsh, the pipeline does not pass text between sequential commands! Instead, objects are passed through the pipeline, with values stored in member variables. This takes some getting used to, but offers some very powerful functionality.
Here’s an example of what a pipeline might look like. The “Get-ChildItem” cmdlet is like the “ls” command in a Unix shell. The “-Force” flag will force things like hidden files to be displayed in the results, and “-Recurse” will include items found in any subdirectories. The “Where-Object” cmdlet is used to filter rows in the output of a command, and the “Select-Object” cmdlet chooses the object member variables we would like to show in a table.
The importing thing to remember here is that objects are being passed through the pipeline. Sorting results for example, would be very difficult given only lines of text! Figures 6 shows how to extend the previous PowerShell command to sort the results by mode and name. Figure 7 shows that because the pipeline passes objects between cmdlets, autocomplete can provide helpful suggestions.
Finally, I’ll show you an example of how all of this can be useful when designing automation scripts. Figure 8 shows a command that finds all in or below the current directory, and branches according to different conditions depending on the item.
As we’ve seen previously, creating a sorted list of items and sorting them is a task well suited to PowerShell. The “ForEach-Object” cmdlet can be used to iterate through the results, and perform different operations on the elements in the list. Again, notice that this is possible because of the object pipeline! We can write conditional statements that reference different member variables, and even invoke methods like .GetHashCode() on certain types of files!
The syntactic differences between the two shells are quite apparent. Unix shell commands are often more brief, and performing simple day-to-day tasks is almost certainly going to be fasted in a shell like this by virtue of the length of the command binaries alone. PowerShell has a distinct style of camel-case, and the ‘$_.Member’ style of referencing the current element in a loop takes a second to adapt to.
The ability to select, filter, and sort items in pipelines is PowerShell’s primary advantage, at the expense of ergonomics. Complex scripts are also much more readable due to the long-windedness: “/bin/ls -ltu” is harder to understand than “Get-ChildItem | Sort-Object -Descending LastWriteTime”.
Figure 9 shows an example of using the Zsh shell to find the names of any text files in the current directory, and save them in a file named “text-files-found.txt”. This sort of thing is similar to what we did earlier with messages from ‘git status.’ Take heed! PowerShell’s pipeline does not work quite the same.
All of this fancy object pipelining, calling methods on results, sorting things, etc. works because objects have types. In fact, you can even create your own custom PowerShell objects!
Figure 10 shows that the name of the generated file receiving redirected output is also included in the “text-files-found.txt” file, even though that command is last in the pipeline. As a result of this typing, order of operations is not explicitly left-to-right in PowerShell.
There’s a ton more that you could say about each shell’s pipeline system, but I tried to cover as much as I could because we were comparing multiple alternatives. Both have valid use cases, and valid drawbacks. Enter “Get-Help about_pipelines” into a PowerShell prompt to get some more information about how pipelining works, have fun!
romaincrisis
baratheonpilled
kaledo-art
gummygunk
pixelskylines
ellievsbear
izzy806
annaxmalina
andulkaphoto
snowghoul
2087