less commands do, more or less, the same things. But do they tell you anything about the users who prefer one or the other? In this post, I'm going to come clean about my biases and some of the advantages of using
less to do more.
I had a conversation with a colleague recently. I’m not especially proud of what I said, but it was a good opportunity for me to think about some things. Here is the conversation in its entirety:
“I don’t trust people who pipe their output through
less instead of
“I feel like they don’t know how to *nix the right way!”
This is what I said. I am not making this up. I even have the IRC chat logs to prove it! I was the one expressing my displeasure with people who use the
less command. But why? What was it that made me feel that way about something as innocuous as a simple pager command? Had these people committed some sort of mortal sin? Was the invocation of
less creating some sort of cosmic imbalance that created an existential issue for the world in which we live that would cause the universe to spin out of control into the great
That sure sounds scary, but I wasn’t even sure when I made those comments what the big problem was.
However, after some soul-searching, I decided that the root of my distrust was that people who use the
less command are somehow newer to Linux than I am, implying that maybe they don’t have the length or depth of experience that I do.
And I’m actually ashamed to say that in researching
less for this post, I found that the command, while about a decade younger than
more, still predates the beginning of my professional career.
So maybe the reason I don’t trust
less users isn’t because they are newer, but because they make me feel like a hypocrite? Or a dinosaur? How dare they?! (Yes, it’s clearly their fault that I feel this way, right? Right?)
But it still feels like
less is a newer addition to the pantheon of Linux commands. And I suppose that’s what foments distrust in the first place: the way we feel about something, regardless of what the facts may actually be.
When 'less' is better than 'more'
What’s the big deal, after all? The commands
less do basically the same thing, right? Yes, basically that’s true. But the fact of the matter is that
less does things differently and, arguably, more efficiently than
Some of the most notable differences between
more are that
allows forward and reverse scrolling,
allows forward and reverse searching,
immediately skips to the end or beginning of the file or output,
allows faster access by not loading the entire file into memory at one time.
Maybe I was wrong? Maybe
less really is better than
more? Could it be?
I have survived other changes, why not this one?
Some of my colleagues still, to this day, enjoy belittling systemd and swear they will never accept it over init. Those colleagues all passed their first Red Hat certifications in the RHEL 5 and RHEL 6 days. I’m old enough to remember that switch, and I disliked it, too. The systemd way of doing things was complicated and different from what I was used to. It seemed that there was a different unit file for everything, even mount points!
The same goes for the GRUB boot loader vs. the old-school LILO boot loader. LILO was so simple and so easy. Sure, it meant that you needed to ensure the kernel and other files for booting fit within the first 1024 cylinders of the disk, but a little hard work always makes things easier, right? Better than learning a new, more complex configuration file format.
And let’s have a moment of silence for our dear friends, Telnet and RSH, shall we? So useful, so easy, even if they were so insecure that they couldn’t be set right even with piles of self-help books.
In the end, though, I’ve come to embrace all of these. Whether it’s the extensibility of systemd, the versatility of grub, or the security of SSH, I have managed to say “goodbye” to my old friends and forge new relationships with the new commands and the new way of doing things.
New kids on the block
I will admit that I have had a difficult time integrating some new things into my daily routine. Take the
dig command, for example. I still find that the bind-utils package is in my default toolkit when I am on a new system because I just can’t pry myself away from
nslookup. But the amount of data we get from
dig is vastly superior, especially when we consider all of the cool things that DNS features make available to us (I’m looking at you, OpenShift routes!).
And while we are talking about networking, what happened to my precious
ifconfig? I did finally make the change to using the
ip command, but wholly against my will. Thank goodness we all have search engines literally at our fingertips so I can look up the syntax each time I have to add an IP address to an interface.
A change that is still on the horizon (for me) is the shift away from
vi (or Vim) to other easier-to-use editors, like
Similar to the
less command, there is a feeling that anyone who is not comfortable in
vi doesn’t really know Linux. Learning how to navigate the ins and outs of
vi has been seen as a rite of passage for any Linux administrator worth their salt. Saying “I don’t really know how to use
vi” basically means “I grew up using Windows and so I never really learned to use a keyboard with more than two fingers” to some people.
Yes, I’ll admit it: I have been one of those people.
But if I step back and examine my own preconceptions and reflect on the common goal of running a stable Linux host, then does it truly matter which tools get us to that end goal?
Technology moves quickly, and with it comes new and interesting ways of doing things. Human nature is such that we like to keep the tools we know how to use simply because we know how to use them. Imagine how hard building a house would be if we had to re-learn how to use a hammer each time. We just want our tools to work. Period.
But there is a major difference between new tools in Linux and a hammer. Actually, there are many differences between Linux tools and a hammer, not the least of which is that one is software and the other is literally hardware. Please don’t use your software tools to drive a nail. I guarantee you will be disappointed with the results. But I digress.
The important difference is that the old Linux tools just don’t work anymore. They left problems for us that the new things just do better. Sure, the old tools may stick around for a long time and serve some purpose, but it’s time to move on. It’s time to embrace new technology and new ways of doing things. Maybe the tools are different, but the concepts are often the same and, more importantly, the end goals are identical.
It’s time to realize that
less really can do
About the author
Matthew Secaur is a Red Hat Senior Technical Account Manager (TAM) for Canada and the Northeast United States. He has expertise in Red Hat OpenShift Platform, Red Hat OpenStack Platform, and Red Hat Ceph Storage.