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.
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 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.
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit