Brushing Up Your vim

vim is a quirky, spartan, powerful text editor derived from the standard UNIX tool vi. If you’ve decided to learn to use it, or want to refresh your memory as to how it works, here are a couple of suggestions.

Use It

Make vim your go-to editor for all your text processing needs. Use it in Linux. Run it on Windows. Make yourself use it regularly and it will become familiar over time.

P.S.: I write all my PowerShell scripts in the Windows version of vim. More on this later.

Play It

This lovely website provides you with hours of entertainment playing a cool game while you learn and internalize the basics of working in vim. As you master the skills needed to defeat the game you’re also becoming adept at handling this most interesting of text editors.

I plan to speak more of vim in the coming weeks, so stay tuned. Be seeing you.

​

xargs: Praise the Lord and Pass the Argument!

One interesting command in UNIX is the little xargs command. It takes something from standard input and passes it as an argument to another command. For example, if a command expects a user name, you can get that name from somewhere and feed it to the command through xargs:

whoami | xargs passwd

The silly example above is also superfluous—passwd can accept a user name through standard input directly, so xargs isn’t needed here. And of course, passwd with no arguments would change the current user’s password anyway. But it is a simple way to illustrate what xargs does. Some commands don’t look for a required argument in the standard input stream, so they won’t read directly from the pipe. xargs takes whatever is in the pipe and sends it as an argument to the command that follows; in this case, passwd.

I personally use xargs in my .xinitrc file to set a random background wallpaper on my desktop when I start X:

find ~/pictures/wallpapers -type f | sort -R | tail -1 | xargs feh --bg-fill

The find command locates all the files in my wallpapers directory. The sort command puts the file names in random order and the tail command grabs only the last one in the list. xargs then passes that to feh, an image display utility, which sets the randomly selected file as my wallpaper. And so X greets me with a surprise every time I go GUI.

Be seeing you.

​

PowerShell: Set Multiple Variables at Once

A list of variable names can be an l-value, that is, an expression that appears on the left side of an assignment operator. Did you know that you could do this…

PS C:\> $FirstName, $Initial, $LastName = 'John', 'Q', 'Public'

This statement will assign each variable the corresponding value on the right of the assignment operator. What if the number of variable names and values doesn’t match? Extra values will be stored as an array in the last variable, so in

PS C:\> $FirstName, $Initial, $LastName = 'John', 'Q', 'Public', 'Sr', 'Esq'

that $LastName variable will be a list containing Public, Sr, and Esq. If there aren’t enough values, the extra variable names are unassigned.

Oh, and if you want to set several variable names to the same value, use this:

PS C:\> $a = $b = $c = $d = 90

Have fun with your variables. Be seeing you.

​

PowerShell - Microsoft's Trident: Part 3, Scripting

PowerShell and Programming

I’ve been examining the three facets of PowerShell that make it such a powerful and useful tool in the hands of the Windows system admin. In this first post I talked about the shell and its ability to plumb the depths of .NET. In the second post I discussed what makes cmdlets so cool and why every kid should want one. In this post we round out our look with…

The Language of PowerShell

Yes, even though it is a shell environment and it has a passel of useful cmdlets, it is also a rich programming (well, scripting) language. If you’ve ever written code in Assembler, C, FORTRAN, BASIC, Java or the like, you can appreciate all the goodness that PowerShell as a language has to offer.

1. Functions

Code reuse is a term that gets tossed about in programming circles, but all that it means is to write and debug your code one time and use it over and over again. Not only does this prevent you from “re-inventing the wheel” but it makes your work easier to maintain. Once you know something works you just keep using it.

To that end PowerShell supports functions, blocks of PowerShell code that can be referred to by name. They look something like this:

function Say-Hello ([String] $Name = 'Anonymous') {
    Write-Host -NoNewLine 'Hello, '
    Write-Host -ForegroundColor Cyan -NoNewLine $Name
    Write-Host '.'
}

This creates a silly little function named Say-Hello that does just that, but in color. However, once we tweak this function to get it to work just the way we want it, all we have to do is call it:

Say-Hello Dave

Now we can drop this function call in anywhere we want to, as long as the function has been defined. Of course, if we want to use it in multiple scripts we really don’t want to have to copy and paste the function into all of them, so that brings us to…

2. Libraries

Libraries are files, PowerShell scripts, that generally contain nothing but definitions: variables and aliases sometimes, but mostly functions. When your script uses a library it can inherit all the names that were defined in that library. Libraries make it easy to write portable functions that may be used anywhere, and that’s what code reuse is all about.

PowerShell supports two different mechanisms for using libraries. You can load any PowerShell script into another using the dot operator to “source” the file, just like you can in UNIX shells:

. $HOME/myScriptsDir/myLibrary.ps1

Note the space after the dot, because it is a command.

If the library has been saved as a module, that is, with a .psm1 extension, it can be managed through PowerShell’s module system and loaded with a cmdlet:

Import-Module $HOME/myScriptsDir/myLibrary.psm1

Modules and dot-sourced scripts each have a place, but both allow you to create libraries of useful functions and easily use them over and over again.

3. Flow Control

Any programming or scripting language is arguably only as strong as its support for flow control, the ability to suddenly change direction at run time when the situation demands it. PowerShell has several tools for creating scripts that can respond to changing circumstances.

• Comparison Operators
  PowerShell contains a fairly rich set of comparison operators and can perform all kinds of tests to see if certain conditions have been met.
• Branching Constructs
  Sometimes you need a script to execute different instructions depending on some condition. PowerShell supports both if and switch keywords for branching to different parts of the script based on useful comparison results.
• Iteration (a.k.a, Looping)
  PowerShell has five different looping constructs built in to the language, not to mention an iterative cmdlet. There are many ways to repeat tasks in PowerShell.

4. Exception Handling

One of the beauties of PowerShell is that is has not one, but two mechanisms for exception handling. The trap keyword creates global error handlers that can be used to create a default behavior should any part of your script throw an exception. The try..catch construct can deal with errors at very specific parts of your script, giving you the flexibility to handle the same error in different ways depending on where in the execution it occurs.

These can each be used alone or combined together in the same script. Each has its strengths and addresses slightly different challenges for dealing with errors, but both give you the tools to ensure that exceptions are caught and dealt with in your PowerShell scripts.

---

Really, PowerShell is a feature-rich language with first-class tools that allow you to write really useful administrative scripts. Of course, what would you expect from the company that brought BASIC to the Altair 8800?

Be seeing you.

​

Those Were (Not) the Days...

In my Linux and UNIX classes I introduce the students to a nifty little CLI tool called cal. Run from the command line, it displays a calendar of the current month with today highlighted. If you have a *nix terminal handy, fire it up and let’s take this little baby for a test drive.

Run cal and you get the calendar for the current month. To see the calendar for the entire year, run cal 2015.

You can also ask cal for a specific month and year. To find the date for Thanksgiving in the year 2020, run cal 11 2020. Pass cal the month and year of your birth and you’ll see what day of the week was graced by that momentous occasion.

But do you want to see something cool? Run cal 9 1752. You might notice something wrong here—September of 1752 is missing eleven days! Is cal broken? Hardly. In September of 1752 the British Empire (finally) adopted the Gregorian calendar to correct an error that was, by that time, eleven days long. What’s cool is that a little UNIX program already knew all that, so you don’t have to worry about accidentally scheduling a Tardis trip for London, September 8, 1752. That is, assuming the Tardis runs a version of UNIX…

So, there’s some trivia for the local pub. Perhaps you can use it to win a few drinks. And watch out for blue police call boxes.

Be seeing you.

​

PowerShell - Microsoft's Trident: Part 2, Cmdlets

The Second Point on the PowerShell Trident

In a previous post I began to look at the three aspects of PowerShell that make it so powerful. In that first article I examined the shell itself, and how it can be used to do some really cool things. Now for the second point…

Cmdlets (/kəˈmandlits/)

Cmdlets are wonderful things. As I stated in that last article, you can run just about any command in the PowerShell shell. But why would you? Between .NET (see that previous article) and the three-thousand-or-so cmdlets in PowerShell 3 and later, anything you need to do from the command line is taken care of.

Yes, initially there will be a bit of a learning curve, but it’s not nearly so bad as you might think, and the advantages far outweigh the inconvenience of learning something new. Besides, as a mentor of mine once said, “The day you stop learning is the day you start dying.” So let’s learn what makes cmdlets so cool.

1. They’re consistent.

If you’ve used any command line environment in the past—CP/M, UNIX, DOS—one source of endless frustration is the lack of consistency among all those commands. “Can you use a space here? Are parameters prefixed with a slash, a dash, two dashes, or not at all? Are they case sensitive?” The very fact that one must even ask such questions makes learning to use the command line difficult and contributes to it’s bad reputation.

But really, it’s foolish to expect anything else. Each of those commands was written by different people at different times to solve different problems. Their authors each had his own experiences and way of thinking that affected how he would address his particular need. It’s only natural that those commands bear little resemblance to one another.

But then came the GUI. When Apple introduced the Lisa in the early eighties it also published a style guide so that developers could write programs that correspond to the system’s look and feel. Microsoft did the same when Windows was released some years later. Building on that experience, Microsoft has provided some recommendations for developers of new cmdlets so that users don’t have to face the arduous task of learning a new set of commands from scratch. In theory, once you learn how to use one cmdlet you can apply that knowledge to any cmdlet. In practice, it works really well.

2. They’re well-documented.

Referring to those operating systems previously mentioned: help in CP/M was non-existent; in DOS it was terse and sometimes cryptic; and while often useful and informative in UNIX the man pages for commands are as diverse and inconsistent as the commands themselves. When a user has to toil by the sweat of his brow to unearth a little information, it’s little wonder that he would run the other way rather than learn how a command works.

PowerShell, though, is actually helpful. The Get-Help cmdlet provides different levels of verbosity, from printing out basic syntax to highlighting every detail of each argument that a cmdlet will accept. It can even display working examples of how a cmdlet is used, which fits my learning style perfectly. You can also search through the help using the standard shell wildcard characters * and ?.

And it’s thorough. Not only can you find information on cmdlets, but concepts are documented as well. Try Get-Help about_arithmetic_operators to find out how PowerShell does math, or Get-Help about_if to review how PowerShell makes decisions. If you need to know something about PowerShell, like Prego spaghetti sauce, “It’s in there.”

3. They return objects.

One of the things that makes it difficult to use command line tools is that they go about their business, perhaps print something on the screen, and leave. This is fine if you happen to be hanging about to read the output, but makes things tough if you want to automate some task in a script. The problem is one of parsing.

Let’s say that I want to fetch a computer’s IP address from DNS and use that address in some other process. I can use:

nslookup www.centriq.com

Since I can see the result on screen, I can parse the output, find the relevant data, and do what I want to with it. Humans are good at this sort of thing; computers, not so much. Let’s try to fetch just the IP address in cmd.exe with some fancier command-fu:

set host=www.centriq.com
for /f "usebackq tokens=2" %%i in (`nslookup %host%`) do set ipaddr=%%i

Now I have a variable called ipaddr that contains the IPv4 address of host, right? Well, maybe. The problem is that nslookup changes its output depending on the information in the DNS record it queries. This command expects the data of interest to be on the last line of output, which will work much of the time, but not always.

Compare that to the following:

$host = 'www.centriq.com'
$ipaddr = resolve-dnsname $host | ? ip4address | select -expand ip4address

If an A record for host exists, the ipaddr variable will always contain an IPv4 address. No doubt about it, and no parsing necessary. The object that PowerShell creates from the Resolve-DNSName cmdlet will have an IP address property that we can directly query and save in a variable.

In fact, all of those objects have useful properties and methods that we can use to customize the output of a cmdlet or even change the state of a computer. These objects can start services, kill processes, change passwords, and so on. They are infinitely more useful than a few lines of text output upon a computer screen.

---

If you’ve ever found the command line infuriating don’t let that stop you from learning how to get what you want from PowerShell. Its cmdlets were designed to address the very frustrations you’ve had with other shells. While learning this new system will require an investment of time and effort, the dividends are definitely worth it.

Stay tuned for part three of this series. Be seeing you.

​