Linux Fu: Build A Better Ls

Ask someone to name all the things they can find in a room. Only a few will mention air. Ask a Linux command line user about programs they use and they may well forget to mention ls. Like air, it is seemingly invisible since it is so everpresent. But is it the best it can be? Sure, you can use environment variables and aliases to make it work a little nicer, but, in fact, it is much the same ls we have used for decades. But there have always been moves to make better ls programs. One of them, exa, was recently deprecated in favor of one of its forks, eza.

One thing we liked about eza is that it is a single file. No strange installation. No multiple files to coordinate. Put it on your path, and you are done. So installation is easy, but why should you install it?

Features

One of the nice features of eza is that it has better defaults. Sure, you can work around that with ls, but it is still nice. It also knows about things like hyperlinks, Git repos, and even icons — sort of.

By default, the program ignores . and .., even if you give the -a option. You can, however, use -a twice to show those directories, as well. Want to know if a file is tracked or ignored in Git? Use the --git option. If you want to see file permissions in octal (and who doesn’t?), try -o. The --git-ignore option allows you to skip things you’ve already told Git not to worry about. You can even get a nice tree-like output (-T).

Column headers are a simple but nice feature (-lh).

A few output lines from eza

Of Course…

Of course, ls has a lot of options, too. You can suppress the . and .. directories, for example, with -A. You can also ask it to create hyperlinks. In fact, if there is one complaint we have, it is that the options are different, and many scripts use ls. So replacing ls with eza can be a problem. You might be better off aliasing it only for commands you enter. It would be nice if, for example, eza took normal ls options until you used a special option to trigger extended options.

If you want, for example, to list only directories using stock ls, you usually use one of two options:

ls -d */ls -l | grep ^d

With eza, you simply say:

eza -D

Then Again…

Eza isn’t going to change your world. In general, you can do everything it does with some combination of existing tools or ls options. But it is handy, especially if you work with tools it knows about like Git. Another common choice is LSDeluxe, known as lsd. This is widely supported and also has a configuration file, so you can make its defaults what you want.

A few output lines from lsd

The lsd program is probably a bit more compatible with ls, which we like. It also offers tree view, icons, and Git modes. One thing we definitely like is the ability to specify –classic to get output similar to what you get from the stock ls.

Overall, they are both pretty similar. Which one you choose will probably fall to your personal preference. Or, maybe you want to stick with the old Unix principle that programs should do one thing and only one thing well. Then you might stick with the old way of doing things, and that’s fine too. Linux is, after all, about choice.

Grep is another one of those tools you might consider replacing. Of course, if you really want a different experience, try changing shells.

27 thoughts on “Linux Fu: Build A Better Ls

    1. I had alias lsd=”ls -d “$*”\.#*(/)” but having it natively is very nice, as you can do more with other options e.g. “eza -DT” is very nice. Also, at least my implementation lsd, is a bit hacky. The eza -D works much better. My eza is aliased to ls (two vs 3 letters) ;P

  1. Add the following to your .bashrc or .profile. Salt to taste (or convert to another shell).
    “`
    export LS_OPTIONS=’–color=auto –classify –escape –group-directories-first’
    alias ls=”ls $LS_OPTIONS”
    “`

        1. Obviously that’s fine too. In theory, one could have different options in different shells/term windows or make changes on the fly. But that’s a corner case.

          In my case it’s just a historical artifact. I use a ~/.bashrc ~/.bashrc.d/*.rc style shell config. At some point the options were in a separate file and I’ve never gone back to modify it. I simply did a cut/past of those two lines for the post.

          Re the .bashrc.d/ style
          It lets me break out my shell configs into multiple file for different purposes. e.g. I have one that configures git related stuff, one for aliases, one for python stuff, etc.

          At the bottom of my .bashrc it has
          “`
          for RC in ${HOME}/.bashrc.d/*.rc ; do
          source $RC
          done
          “`

      1. The man page would indicate the long form arguments are just as valid and I find it more readable. But it’s your RC so whatever you prefer/works for you is totally valid.

    1. What I generally do is:

      find / -name “looking_for” -print 2>/dev/null

      Doing the 2>/dev/null will eliminate the errors messages.

      If you expect a lot of output you can:

      find / -name “looking_for” -print 2>/dev/null | more

      Pipe output to more to page the output.

    1. This. I type ‘ls’ so many times during a typical workday, and it rolls off the fingers really easily. ‘eza’ is far too awkward. As least ‘lsd’ is easy to type and it shares many of the commonly-used options with ls.

      1. alias is your friend, lots of people have ll aliased to ‘ls -l’ so you could use ll to alias to eza instead. As an added bonus it will leave ls alone, so when it is used in scripts (never seen that in practice though), it will still function as intended.

  2. Annoyingly, the installation of ls in linux is broken by the common .bashrc file. It purports to allow simply enabling/disabling of the rather useless colours (which always have some unreadable choices whether you use a dark or light terminal) due to having a too-indirect control of the option.

    This results in a choice being made that’s then overidden by some differently prioritised options. I can only assume that some previous maintainer was so frustrated by one scheme that they plastered another one on top.

    I get that some people think dark mode is trendy. But many of us got over it with green on black in the 80s and are rather glad to have a screen that’s compatible with workbench lighting. Please test your text colour screens in other backgrounds if you want them to be more widely useful.

    1. Adrian said: I get that some people think dark mode is trendy.

      IT IS NOT trendy for many. I for one have sensitivity to bright colors. I use dark mode when possible.

      Please choose your words more carefully. Thank you.

      1. Nonetheless, that seems to be the most common reason behind using it. I hate hackaday’s presentation, find it very hard to read. Whatever you find undesirable about light colours I find undesirable about dark backgrounds.

      2. Note that a dark screen is inherently more difficult to read because of physics/optics. Low light means wide pupils. Wide pupils means short depth of field. Bright conditions give deeper fields and less tiring vision.
        If you have difficulties for other reasons then I’m sorry that you have to deal with it, but due to aging most people will progressively prefer the opposite.

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.