Load Average: those funny little numbers

I was going to write a little article on interpreting the load average in UNIX and Linux machines, but I ran across this blog post and don’t think I could have said it better. Really, check it out.

When I’m logged into a graphical session on my FreeBSD system I use conky to monitor hardware utilization and performance (and the local weather and unread messages in my GMail inbox, etc.) But normally I work from the command line with ssh and tmux, so I have created an alias that I load in my login profile to let me get at the load average in a quick-and-easy fashion:

alias loadavg='sysctl vm.loadavg | cut -d" " -f3,4,5'

Now I just run loadavg any time I want to see how my cpu cores are doing.

Be seeing you.

​

I'm an Alias, I'm a Legal Alias

Useful Command Aliases

When working from the command line I like to cut down on the amount of typing that I do because a) I get in a hurry, and b) I fat-finger the things I’m trying to type, so c) I end up doing things over to get them right. I use aliases to take some common tasks and shorten them up so that I can save time and face.

If you look at my *nix systems you’ll find several aliases for various incarnations of ls:

alias l='ls -F'
alias la='ls -a'
alias ll='ls -lh'

The first of these, -F, appends a character to the end of the file name to identify the file type: * for executable files; @ for symbolic links; and / for directories. Regular files don’t have any special character following their names. While most Linuxes and BSDs use a colorized ls command these days, this is useful if you need to work from a terminal or remote session that doesn’t support color.

The second alias lists all files, including hidden ones, and the third displays a detailed listing with file sizes in “human readable” format: gigabytes or megabytes instead of bytes.

Aliases can be more sophisticated, standing for piped output. When I use the df command to check free disk space, usually I just want to see mounted logical volumes and not pseudo-filesystems and LVM disks. I pipe the output of df to grep to get what I want:

alias dfh='df -h | grep -v "^[[:alpha:]]"'

And to see a sorted list of details about my own processes:

alias myps='ps aux | grep ^$(whoami) | sort -k 2b'

An alias can also contain several commands—a mini-script, if you will:

alias sched='echo ""; cal; echo ""; calendar -w 3; echo ""'

Perhaps I have inspired you to experiment with aliases and discover some of the cool things you can do with them.

Be seeing you.

​

PowerShell and Chocolatey Goodness

A movement has long been afoot to bring a useful package management system to Windows. If you’ve used apt or yum or yast or some similar tool in a Linux distribution, then you know how easy it can be to install new software to your computer with the right utility. Enter chocolatey, the PowerShell package manager for Windows.

Before starting a new class I make sure I load up my instructor computer with my favorite text editor and my chosen file manager:

choco install -y vim doublecmd

If I’m going to play videos for my class, I may also add a nice player:

choco install vlc

Of course, if I see that the machine I’m using has an older version of PowerShell I may want to update that:

choco install -y powershell4

What if I don’t know the name of the package I want? If I want to install the Angry IP network scan tool but know not what the package is called, I’ll ask chocolatey:

choco search angry

This is such a cool tool that rumor has it that even Microsoft is interested in using it. We’ll see. Perhaps managing software in Windows will soon be as easy as it is in Linux.

Bee 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.

​

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.

​

PowerShell(s) of Two

While writing out some IP addressing exercises I needed a quick reminder of some of the powers of 2 that I use a little less frequently. I just opened up a PowerShell console and made a little table like this:

foreach ($i in 0..32) {"{0,8} {1,-11}" -f $i, ([System.Math]::Pow(2, $i))}

Hope you find this useful. Be seeing you.

​

PowerShell - Microsoft's Trident: Part 1, the Shell

The Three Tines of PowerShell

Like the powerful trident in the hands of Poseidon, PowerShell can be wielded for good or ill. It can create vast wellsprings of new possibilities for the savvy administrator and unleash destructive floods of complexity on the uninitiated. To some it solves many problems, to others it is the source of many headaches.

What I want to examine now, though, is the triune nature of this beast. Like Poseidon’s legendary weapon, PowerShell takes a three-pronged poke at the issues that commonly beset us in IT.

The Shell

PowerShell is a shell. That is, it’s an environment in which you can type commands to get your computer to do something. But it’s a really cool shell.

1. It gives you direct access to .NET.

I can’t stress this enough. .NET. From the command line. At your fingertips at all times, ready to do your bidding. If there is anything you must know about PowerShell, it is this. Almost anything that can be done in .NET can be done from the command line in PowerShell. Do you want to get data from a web server?

[System.Net.WebRequest]::Create('http://www.mysite.com/index.html')

Do you want to place the cursor somewhere particular on the screen?

$Host.UI.RawUI.CursorPosition = @{x = 20; y = 47}

I’m talking about some cool stuff. For example, Microsoft failed to give us an equivalent to the DOS ‘pause’ command in the initial release of PowerShell, and their eventual addition of a comparable function is lame. That’s because PowerShell can’t respond when you “Press any key to continue…” It doesn’t know you’ve pressed a key until you hit Enter and send to it the contents of the keyboard buffer. But .NET can access the keyboard at a lower level, bypassing the buffer:

function Wait-Key {
<#
.SYNOPSIS
Prompts the user to press a key and waits until the user does so.
.DESCRIPTION
The Wait-Key function simulates the DOS program pause. It gives a script an
opportunity to wait for the user to press a key before proceeding.
.PARAMETER Message
The prompt message to display when the script pauses.
#>
        [CmdletBinding()] param (
            [string] $Message = "Press any key to continue..."
        )

        $Message
        $Host.UI.RawUI.ReadKey("NoEcho, IncludeKeyDown") | Out-Null

}      # end function Wait-Key

With .NET and the MSDN website at your beck and call your command-fu is only limited by your imagination.

2. It allows you to run any command.*

From PowerShell you can launch any graphical program. Open up a text file in notepad or an html report in your default web browser.

notepad .\seating_chart.txt
Invoke-Expression ./disk_report.html

You can run any command-line utility…

ipconfig /displaydns

… even old CLI tools whose arcane syntax can cause PowerShell to balk—when you use the --% operator between the command and it’s arguments.

ICACLS.EXE --% C:\TEST /GRANT USERS:(F)

* Okay, so not really ANY command. You can’t run commands that are built in to the old CMD.EXE or COMMAND.COM command shells. This makes sense, as those commands are not stand-alone tools but are BUILT-IN. That’s why there’s point number 3.

3. PowerShell has cool aliases for useful commands.

As stated in the caveat above, CMD.EXE had several commands integrated into the shell itself. There are no executables for DIR or CD or DEL, so you can’t get at those from PowerShell. However, Microsoft has borrowed a page from other shells and given us aliases. While not quite as useful as the UNIX implementation of the concept they do allow us to create familiar or shortened names for common commands. So I can type DIR—or ls for that matter—and get a directory listing. Granted, what I get is not the result of DIR but the PowerShell Get-ChildItem command, so things are a little different, but not completely alien. I can easily create aliases of my own, if I like:

Set-Alias -Name unlink -Value Remove-Item
Set-Alias -Name goto -Value Set-Location

With aliases I can customize the shell to suit the way I prefer to work. To me, that makes PowerShell the best Windows shell around.

---

So stop using that old command interpreter. PowerShell is a much better shell than anything Microsoft has given us before, and with it we can do so much more than CMD will allow. And stay tuned for the other two prongs in the PowerShell trident.

Be seeing you.

​

make mine a double

using the copy command

when managing a windows server i sometimes find myself needing to copy many files. for the sake of efficiency i head for the command line. the copy command can be used to quickly make a copy of a file:

C:\>copy q1report.txt q2report.txt

this copy command takes two arguments. the first is the file to copy, the second is the name of the new file to create. when you just want to make a copy of a file in a new location, use the destination directory as the second argument:

C:\>copy q1report.txt reports

this will make a copy of q1report.txt in the c:\reports directory. you can copy multiple files at once using wildcards:

C:\>copy q*report.txt reports

retaining permissions with xcopy

when you copy a file only the contents are duplicated. a file's permissions don't copy with it, but the duplicate inherits the permissions of the directory where it gets created. if you want to copy both the file and its access control list, you'll need to use xcopy:

C:\>xcopy /o q1report.txt reports

xcopy can also be used to copy whole directory trees:

C:\>xcopy /s reports d:\

this command will copy the entire directory structure under c:\reports to drive d.

concatenating files with copy

when you need to combine several files into one the copy command can be used for concatenation. just join all the old filenames together with plus symbols and specify the new filename.

C:\>copy q1report.txt+q2report.txt+q3report.txt+q4report.txt annual_report.txt

this works great for combining ascii text files together, but it's not generally very useful with binary files like those created by a word processor.

copy as a text editor

the copy command can also be used as a quick-and-dirty plain text editor. start with the command copy con filename and then type the lines you want in your file. when you're done, type ctrl-z.

C:\>copy con ls.bat
@echo off
dir
^Z

now your batch file is saved and ready to rock 'n' roll.

for more advanced features, check out the command line help for copy and xcopy, and, as always, be seeing you.