An old IT ninja learns new Unix tricks

It was with some fascination that I happened across Ian Langworth’s “VIM after 11 years” post last week. As a vi/vim user for more than 20 years, I wasn’t expecting to learn much. But to my surprise, Langworth revealed many features and tweaks I never would’ve sought out on my own because — well, why would I? My vim reflexes have been built up like calluses over decades, long before many of these features and plug-ins were a glimmer in anyone’s eye.

Yet I found some very old features that I either never knew about or used so sparingly that they’ve been archived. The :g// command was one of those items. Despite the fact that :g/re/p in the ed editor was the original impetus for Ken Thompson to write the first stand-alone grep utility, I’ve never really used :g// in vi/vim. It just never worked its way into my reflexes. In hindsight, that’s hard to believe, but I’m apparently not alone in that regard, as Langworth noted in a follow-up article.

[ Also on InfoWorld: 13 killer open source admin tools | 9 traits of the veteran Unix admin | Track the latest trends in open source with InfoWorld’s Open Sources blog and Technology: Open Source newsletter. ]

The fact is we get mental calluses when we use the same tools over and over again. We stop thinking about how to do something and instead rely on our reflexes. Because we’ve stopped thinking about the mechanics, it’s easy to miss updates and advances to the tool.

I’d also posit that these calluses are more likely to occur in regard to CLI tools than GUI tools, because we tend to notice new menus or new options in drop-down lists or new check boxes in a dialog. In a CLI app, especially a CLI utility rather than an editor like vi, options and features are masked. To find them, you need to call up the man page.

A great example of this is the Unix less command. The less command has been in development for decades. Recent CentOS and Debian installations use version 436. For those familiar with the tool, this might seem a bit absurd.

After all, this is a tool that simply handles pagination of long text files, as well as the ability to move forward and backward within the file. Completely unscientifically, I would estimate that 95 percent of all uses of the less utility involve little more than hitting space bar or Enter to advance the text, and Ctrl-B to back up a page. A relatively small number of uses will leverage the / search capabilities. An even tinier number will use regular expressions in those searches. It’s the less command, for pete’s sake — it’s a very simple tool.

However, 34 command-line switches are available for the current version of the less command — seriously, 34. Check out the man page. And there’s more, including all kinds of navigation commands that go well beyond the rudiments, multiple file management commands, and a huge range of tweaks.

Frankly, it’s amazing. I’ve probably typed less commands between five and 100 times a day for decades, and I had no idea the extent of the development of less, nor had I any notion of what it can really do. The developer, Mark Nudelman, is hardly done; he’s at version 451.

I definitely don’t mean to single out the less utility here. It’s a vital part of any Unix-like OS, and no doubt every improvement has been made to address an issue or feature request someone had at some point.

I’m just using less as an example of how the tools we use are constantly growing and changing, often without our awareness, right under our fingertips. Unless we have a specific need to perform a very specific task, we rarely poke around under the covers. If we once read a man page for less back in 1995, chances are we haven’t looked at it since. Little did we know that we not only can customize our less prompt, but we can use 16 variables and 15 conditionals to do so. The mind boggles.

That’s why I enjoyed Langworth’s post so much. It spurred me to go back and dust off those old reflexes and hopefully create new ones. I spend a lot of time in vim, and what he’s unearthed is likely to save me considerable effort over the next few decades.

After all, every once in a while we should rip off those calluses and learn better ways to do things. Our tools have never stopped growing. We should take the time to notice.

This story, “An old IT ninja learns new Unix tricks,” was originally published at InfoWorld.com. Read more of Paul Venezia’s The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.