The more and 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 more."

“Why not?”

“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 /dev/null

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 more and 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 more.

Some of the most notable differences between less and more are that less:

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

Digital-Transformation-Minispot-Technology-illustration-quote copy_Blog-thumbnail.pngNew 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 nano

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?

Conclusion

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


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.

Read full bio