A Collection Of Linux Tools On Steroids

Sometimes we do things because “that’s the way we’ve always done them.” Screws, for example, had slotted heads in the 1500s and slotted heads are notoriously bad, but despite Robertson in 1907 and Phillips in the 1930s, it took decades for slotted screw heads to become uncommon and they still lurk in a few areas. Many Linux tools we use every day are direct descendants from Unix tools that have been around for almost half a century. We’ve looked at a few more modern alternatives before, and [ibraheemdev] has a GitHub collection of many such tools that’s worth checking out.

Of course, modern doesn’t always mean better. However, the tools in the list do have great features including things that were uncommon in the old days such as the use of color, text-based graphics, and things like git integration.

Some of the commands replace very common commands. For example, bat is like cat with syntax coloring and git integration. The exa and lsd commands are like ls, and lsd is even compatible with ls. There’s delta for replacing diff, and duf or dust to replace du. Instead of cd, you can use zoxide to get some advanced capabilities that are native so some shells.

Many of the commands offer less power to make common tasks easier. For example, you can use sed to search and replace text, but sd is easier. You can use cut to pull parts of a file or stream out, but choose makes it easier. Sometimes the man command gives you too much detailed information. The tldr and tealdeer commands give you just the common options for commands and cheat offers interactive cheat sheets.

Rounding out the list are commands that offer dedicated network help where you might use telnet, wget, or curl. Programs like xh, curlie, and httpie, for example, offer easier ways to do various network requests.

You might not use every command on this list, and finger memory is very powerful (although you can always create an alias if you are brave enough). However, you’ll probably find one or two interesting commands that become part of your workflow if they aren’t already.

We’ve talked about some of these tools in previous Linux Fu posts, but having these in one collection is handy and — we presume — the list will update from time to time, so it is worth watching the project on GitHub.

This isn’t the first time we’ve seen a list like this, although each seems to have some things the other ones don’t. If you find yourself often composing difficult command lines, check out Marker, which can help.

Banner image: “penguin group small” by Antarctica Bound. CC BY-ND 2.0

75 thoughts on “A Collection Of Linux Tools On Steroids

  1. As an old Unix guy who absolutely hates colored text. I can only laugh. It’s the first thing I disable if the system does that. I use bold black on white.

    Why? Because the focal distance for the human eye is color dependent which makes colored text harder to read. I learned this in 1982 when I first encountered an IBM 3279. Not to mention that yellow on white is *very* hard to read. The 3279 was black background, but even with a black background the eye fatigue was very noticeable after a short period of time.

    My personal observation is that traditional Unix tools are a distinct improvement on their successors. As was popularly remarked about Algol 60 when Algol 68 appeared.

    But if you like it, have fun. Just keep some aspirin or acetaminophen handy.

    1. At the begining of the 1980s I worked on 3277 terminals / green on a black background. And this caused eye fatigue due to the constant variations in contrast with the paper documents always necessary for software developers.

      At that time me and other colleagues were the subjects of a study made by an ophthalmic intern for his thesis on eye fatigue. The conclusions of this study clearly showed the link with the differences in contrast and the resulting temporary decrease in visual acuity / headache.

      Later I worked on much more efficient Memorex color terminals with VM / CMS and therefore an editable background color. Obviously nobody used the black / dark background anymore and as a result the eye fatigue disappeared.

      I have also worked on an IBM 3279G / GDDM graphics terminal : it was part fun and part nightmare to use.

      1. As you mentioned, the issue is more with disparate contrasts and background colors than with the background color. Having a consistent environment – be it light or dark background – is much more important than the color itself. Personally, the only times where the background color is important is when working in a dim room, or even during the night. And in those cases I curse at white themes.

        That said, it is pretty easy to tune things to reduce eye strain with modern systems. Lower the brightness of you screen, seriously, do it. Tune you terminal/IDE/etc color scheme to never have pure colors, especially pure white on pure black (try to set the background color of HAD to pure black, and see how it hurts). Install theming extensions to get a consistent look (e.g. dark background on the whole web). Use a system-wide software to reduce blue light when the night come (I cannot stress this one enough, this is the biggest gamechanger when you spend your time in front of a computer).

    2. Red on Black (or Black on Red) is difficult for the long sighted. It just looks like a blur.
      I simply cannot read most Linux error messages! I can read the (unimportant) notes and warnings, but not the (important) errors.

      Many utilities will suppress the colouring if they detect that they’re not writing to a screen. I can fix e.g. dmesg like this:

      dmesg | cat

    3. I usually love the default color schemes for commandline stuff such as directory listings. But what is it with Emacs and yellow messages? Every time I think I found the setting to get rid of the yellow once and for all I find a new yellow prompt.

      I guess it’s fine when I’m actually running Emacs at the commandline but if I let it open in an x based window… yellow on offwhite.. totally unreadable! Who thought that was a good idea?

      1. That “not such a good idea” is probably based upon “computer screen is dark, text on that screen is light”.

        We do need to make a telephone call to 1975 or 1980 and warn them that the future will have computer screens that are light. And ask for avoiding terminology like “reverse video”.

    4. I can not agree with you strongly enough. Whoever came out with the colored text output needs to be flogged.

      I dunno about linux anymore. For the most part it has become what we used to mock about Windows.

    5. I think colored text is a great help, but I think some of the default color choices that are used are awful. Using full-on-red/no-green/no-blue (or other similar primaries) is usually a bad choice, for reasons that you mentioned.

    6. That color focal distance does make sense. I’ve been wondering why coloured terminal text sometimes looks three-dimensional, like different colors are floating at different depths. It only works with strong basic colors though, so it’s only an occasional distraction.

    7. As an old unix guy, I love those kind of improvements. _especially_ color ones. When I open some source code in vim and it appears in b&w, it surely remembers me of the old days, but i hate that. Color syntaxing is great.

    8. But that’s the thing, you don’t need to focus if you have colors, as the peripheral vision will be quick to catch errors or syntax problems. While I might agree with the focusing difference (sounds like chromatic aberration) I’m not sure how much difference it makes for those distances.
      It very much sounds like you want to live in the 70s, and there’s nothing wrong with that option. Plenty of IT people choose to, the overwhelming majority doesn’t.

    1. ripgrep supports many features found in grep, such as showing the context of search results, searching multiple patterns, highlighting matches with color and full Unicode support. Unlike GNU grep, ripgrep stays fast while supporting Unicode (which is always on). ripgrep has optional support for switching its regex engine to use PCRE2.

      1. I did. The problem I had was the syntax was too jarring. They didn’t even try to make it like C. Honestly, Rust could have been a nice extension of C++ but they didn’t even try. I still think their strongest features (memory safety) can be integrated into a C++ compiler.

    1. I thought the same. gawk is faster and supports more complex operations than awk. Some people claim it is an good built-in option to process large amounts of simple numerical data, without needing to install overkill math libraries.

  2. The main benefit of learning and using the “standard” tools is that they’re available almost everywhere.

    Ssh somewhere and you may not have access to bat, lsd, or delta anymore (probably fixable, but not always).

    That said, there are differences between between GNU tools and BSD that may bite you even though both have exactly the same name.

    With the recent developments in the FSF there’s an argument for looking elsewhere than GNU and with so many alternate tools – that often are compatible with what they replace – available it might actually be possible to set up a Linux system without (or at least with less) GNU tools.

    1. “With the recent developments in the FSF there’s an argument for looking elsewhere than GNU”

      i’ve never been a big fan of rms but he’s right. you need to keep your eye on the ball. if you start making technical decisions around social fads you’re gonna wind up making poor decisions. rms has always been rms and has been an important part of making the systems we use today, even the “alternative” ones. if you meet non-rms programmers, you’ll see they’re often just as ‘problematic’. cancelling rms doesn’t fix your software, or its pedigree.

      1. I hate slotted screws with a passion. If I could choose there’d be torx everywhere though hex works almost as well for most cases.

        If it’s looks you’re after I think hex looks good too.

      2. Back in the 80s Sony would use special “slots and dots” screws in their broadcast video equipment. The first time I saw one I asked, “Why is there a small round hole in the middle of the slot?” Then another engineer showed me the appropriate screwdriver, which had a corresponding round protrusion in the blade. This kept the bit from slipping out of the slot while you turned the screw.

        These were mostly used on covers and panels that would be removed frequently for maintenance, having the added benefit of still working with a standard screwdriver.

    1. Slotted screws are used in boat building, because it’s a lot easier to clean out a single slot, than the head of a Phillips (etc) screw. That’s useful when you might have to undo a screw after decades of it being in a boat, (and covered in filler etc.)

  3. It’s actually their aggressive marketing [1] which is keeping me away from them (OK, with go, there’s Google as a second repellant).

    It feels like that used cars salesman I always have an urge to politely smile at, then try to find the quickest way away from.

    [1] Perhaps it has something to do that Google and Mozilla are both ad-fuelled entities?

  4. Why we still using make? The syntax seems to have been designed to make sure the moment you walk away from the make file you have forgotten how you wrote it.

    1. works, widely available. the alternatives always leave you in the lurch when you go to port it or run it on a different computer. most of them aren’t available on “older” OS distributions (sunos, or whatever), but the ones that are actively maintained are actually worse, they will break themselves after you “apt-get upgrade”. every @!#$in time. i’m lookin at you, gradle.

      i also have a ton of complaints about make but at work we’ve got awful cobbled-together makefiles that work on AIX, sunos, old freebsd, new freebsd, old linux, new linux, and even on windows. every time i go to change them, i say, “this is awful,” but every time i go to build — anywhere! — it works or the path to fixing it is clear. there’s no reason something else couldn’t achieve that feat but it hasn’t happened yet.

      it’s really hard to improve on “works”.

      1. Clearly foss programmer need makefiles from your work place.
        On small project (2-3 dependencies ) it almost always works
        On medium sized it already drop to 50% chance of failure trying to build.

        On larger project forget it, it will NOT work.
        I guess that is one of the price of complex codebase.

      1. tldr, bat, httpie, these are POSIX??? When did that happen???

        Every time I see a new command that tries to supplant an old one, I think “solution in search of problem” and “snake oil”.

    2. TLDR: I still use (gnu) make.

      In the beginning there was C and life was good, but not good enough. So the shell was invented. And life was good, but not good enough. So make was invented. and life was good enough.

      But not good enough for some people. So autoconf was invented, and then automake (because autoconf is incomprehensible). And, sorry, but you lost me.

      So cmake was invented. And the same thing.

      Make and shell scripting work (as noted below), are sufficient, easy to understand if done properly, require no other tools or dependencies.

  5. There is something broken on this site. I see your introduction… But not the list itself and checking the references too other related stories I get the same effect. I probably could switch to a desktop browser to fix this but I’m using a mobile browser (brave on iphone) and have the ad blocker turned off. So you may want to check out your own tools before recommending others.

    1. I was curious about this (I’ve actually been meaning to try Brave and test its functionality), so I just installed Brave on my phone, and everything works identically to the desktop version, with all the default browser options, including “Brave shield” enabled for this site. I wonder if it’s a certain setting you have, or possibly a difference between the iPhone Brave app and the Android Brave app (I’m using Android 8.0, for reference). It actually works REALLY fast, too, which I am pleased about. I tested all the links, and they load almost instantly. I’m not sure if this is helpful, but maybe it will help you isolate your current browser setup or a bug in the iPhone version as the issue, as opposed to the website. Thanks for the reminder to try Brave! This thing is screaming fast on some websites :)

  6. I googled LSD and apparently you need a dealer to get it. But it appears to make things more colourful indeed! On a more productive side of things: I really love those little tips and tricks and would like to mention the fish shell which I really love.

  7. I just discovered a little gem: using less to read through multiple files, you have to type colon-n (:n) to move to the next file in turn, which required both hands and is awkward.
    To fix that. Create a file~/.lesskey containing
    \e\n next-file
    And run the command lesskey
    Now typing alt-enter will move to the next file

      1. I have no issue holding right alt with my right thumb and tapping enter with my right pinky whenever I need an alt-enter.

        In the above example it’s also fewer keystrokes, no matter how many hands you may or may not have, which is helpful.

  8. It’s true, there are some really nice replacements for the old-standard tools out there.
    But…

    If you want to be able to use a fresh system where you may not even have permission to install your favorite new tools…
    You have to learn the old tools.

    If you want to understand 99% of the scripts that other people wrote…
    You have to learn the old tools.

    So in short, you have to learn the old tools.

    And if you don’t have time to learn two or more of everything…
    Then you aren’t going to learn the new tools.

    So you continue to use the old tools.

    What’s the solution to this problem?
    Get more people using the new tools.

    Doh!

  9. Two of my more recent faves have been “ncdu” which will show you disk usage of files/folders and has some moving/deleting functions, and then “tmsu” which allows you to tag your files with useful descriptions. It even creates a pseudo-filesystem where you can browse the files under the tags.

  10. When I started learning UNIX in 1985 (with my copy of K&R and The Manual in hand) I read through every man page for every command I found in the (System V R2) bins. There were maybe 150 or so commands. Contrast that with today, where we have literally thousands of commands related to a wide variety of utilities and languages. Personally, being color blind is a bit of a challenge with what seems to be an ever-increasing tendency to colorize nearly everything. My profile has become quite complex in trying to keep up with this.

    The ip command has replaced ifconfig, systemd (love it or hate it) has replaced existing init frameworks. This evolution will continue, likely forever, as UNIX/Linux continues to grow and morph. There is never complete consensus on any change, and the OS will continue to branch and fork to create specific distros that appeal to groups of folks with the same taste and/or needs. New commands (like the above) will find their way into upstream, and will become part of the OS over time. We will continue to find ways to set our color (or non-color) preferences to deal with the blue on black and red on black “defaults” that will continue to plague us.

    Life is change. Embrace life.

  11. Some of the entries are absolutely ridiculous.

    gtop – its like htop except…

    you run it as a service in a docker container. its written in JS and displays a UI in your terminal. bonus points for donut charts to show disk usage.
    if only there was some way to display things using javascript…

    not only does it completely miss the point of htop, its like they purposefully chose the completely wrong tools for the job and threw in docker for good measure because containers are must have technology of the decade.

    1. This. Looked over the code and it looks like docker is optional but node.js is obviously not, but the irony of this app is in the issues and pull requests that want everything htop can do. Why would you want to replace something that’s very low level with something that needs an interpreter and is an order of magnitude slower and would likely be a hog on your processor in the first place? For the most part, it puts a pretty face on the systeminformation library, which at its core just calls the old tools like cat and ps anyway, saving no efficiency, time, or anything else. At least glances gives you a web version and it works almost identically with Python which is more likely to be installed than nodejs.

  12. In my opinion, it is not OK to impose colored terminal output on a user by default (unless the very point of the utility, like a text-based image converter, is to display colored graphics).

    Doing so imposes your color choices on your users, and risks making your tool unusable by (1) people whose choice of background color happens to be different from yours, like me, (2) possibly people whose choice of default foreground color happens to be different from yours, (3) people who are even partially color blind, like me, (4) people who are entirely blind and rely on text-to-speech or other technologies, (5) people trying to use your tool on monochrome displays (which hasn’t been a thing for a while but is likely to be more so as e-ink gains marketshare, and (6) people with taste and decency.

    Fine to have it as an option, especially if the colors are configurable, but if my *first* impression of your tool is digging into documentation to figure out how to make its output legible and not hideously ugly, I am going to go looking for another tool (and avoid other things in the future that have your name on them).

    (I feel much less strongly about other attributes like bold, italic, and underlined text, since they’re less likely to break with my color blindness and background choices, but they still cause problems for (4), or people using otherwise limited terminals.)

    1. I 100% disagree.

      I like keeping default settings. So I prefer the defaults not suck.

      I used to customize everything on my desktop. But that just made using fresh installs, machines I don’t own, etc.. feel awkward and backward when they didn’t have the customization I was used to. By training myself to use the default key bindings, scan my eyes across the screen looking for the default color of the kind of information I am looking for, it’s like every default install IS my custom home environment.

      Except.. oh wait.. default colors is no color. Almost everything defaults to black and headache inducing white. Oh yay! Scrolling my eyes across pages and columns of a directory listing when everything looks the same It is Oh so fun! Why did we get rid of our old green or amber monitors CRTs again? Weren’t those just the best?

      How terrible it would be if the default included all that nice color coding where filenames are easily distinguishable from directory names and executables stand out from data so if you know what you are looking for your eye is almost drawn to it by the color code?

      With all due appoligies to the color blind. Computers should be accessible. But by options that can be set, not necessarily by defaults. OSs don’t usually install with screen readers turned on by default. They don’t need to be monochrome by default either.

      1. “suck” is an opinion. There is -no- -way- to disable color text from more than a few Linux programs. I’d gladly put “export COLORS=never” in my .rc files but -it-doesn’t-work. I’ve dug throug source code, sorry. -You- can set foreground & background colors on your terminal emulator so you never see “headache inducing white”. Six plus percent of the population isn’t happy as well as older folks whose vision is not 20/10.

  13. Since I don’t have an extensive Linux background I find myself asking dumb questions. For instance, I know how to clone a repo such as the moden-unix repo mentioned above. But now it is like the dog that caught the bus, How do I use it. I tried for instance running “bat” but got an error saying it was not installed. Reading the Readme file was of now help.
    So how do I actually install these “moden-unix” commands so I can try them out?
    Thanks for the help.

  14. Pandering.

    “Linux” is more marketable than “Unix”, so you rewrite the title? The word “Linux” appears ONCE on the linked site, and it has absolutely nothing to do with the title. This makes me sad. Hackaday is really losing my respect, between “Linux”ing everything and the neverending cookie BS.

  15. Then there’s all the garbage that replaced things that didn’t need replacing because of this “if it’s old it must die” sickness that’s crept into open source now too.
    Garbage tools like IP. And before you tell me I’m wrong and it’s better than ifconfig, type “ip” by itself with no arguments at a shell and tell me with a straight face that’s ok behaviour for any tool!

    Then type “man ip” and let the stink of insanity waft over you

    These are the same people that brought us all the mebibyte nonsense, which I’ll accept the day all our computers run on base 10 logic.

    1. I’m with you on the mebibytes. Good for selling storage devices by lying about their capacity but computers use integer powers of 2. It might be OK in a GUI but console applications have a more discerning user base. LVM and mdadm do it properly so why can’t fdisk and df?

  16. All I can even find on the github is a readme file and nothing else.
    As a pleb like me there isn’t even a way of installing any of this.
    Just feels like a big joke and a lot of talk of how cool it all is, but
    there’s no instructions anywhere. Just a file showing what I have
    already seen on the page.

    Am I missing something here?

  17. Dear Al

    Thanks for introducing me to some new commands

    Like many of the other commentators, I am an old unix/linux/greybearded guy but I like streamlined input and the coloured/structured output when I can actually read it (tweaks may be required). It’s always good to check out new stuff and so thanks very much for alerting us to what’s out there! I’m sure I’ll end up using some of it

    Cheers Pete

  18. Apologies! Late to the party AND responding to a tangent.

    The discussion regarding optimum color coding choices piqued my interest. Maybe this is could be a nice Hackaday article? Or would it just start a religious war?

    It’s probably very personal or biologically tuned but what would be a great color scheme for the C language? The Turbo Pascal era made a big impression on me and I still use a white text on dark blue background; keywords and operators in yellow; comments in green; numbers and strings in light blue; preprocessor in red etc. I would love to have a scheme that also works well with a white background so that I can flip between the two.

    Regards,
    Pieter

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.