Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Is this intended as a full on ls replacement? As in, does it respect the envvars such as lscolors? Will it silently ignore -h, or will it die violently?


From the FAQ:

>Is this a drop-in replacement for ls? No — exa has, in my opinion, much saner defaults than ls, so while the available command-line options are similar, they are not exactly the same. Most of the common options will work consistently, though. For example, exa prints human-readable file sizes by default (when would you not want that?) so ls -h no longer applies.


"exa prints human-readable file sizes by default (when would you not want that?)"

When doing automated text-processing and wanting to easily do precise calculations, without having to deal with different units.


The important part is by default. exa can provide bytes sizes, it just provides human-readable ones by default.


How does the number of bytes help with text processing? Are all your files in fixed-length encodings?


Probably means "when processing ls output", in which case not having to do prefix conversion is easier.


I almost never use the human-readable file sizes.

For this to get any traction it is going to need to accept every argument ls does and play nicely. Most people who work with nix systems work on many systems and some of them don't control the software loaded on them. If I have to remember that on this* system I have to use these arguments because I have exa, vs this system I have normal ls that is going to be a deal breaker for many.


> I almost never use the human-readable file sizes.

Same here. I love the idea, and i keep trying to use human-readable sizes in every command which supports them. But it turns out they're much less scannable than numbers in a common unit. How long does it take you to see which of these files is biggest:

  13k  potatoes.txt
   7M  tomatoes.txt
  128  recipe_ideas.txt
   1G  hot_sauce_formula.txt
How about now:

       13093  potatoes.txt
     7182642  tomatoes.txt
         128  recipe_ideas.txt
  1023984672  hot_sauce_formula.txt
Human-readable numbers also break all sorts of useful things like sorting (unless you have some fancypants sort which understands them), calculating totals with awk, sedding them into an expression to evaluate with $(()), etc.


Interesting point. Maybe we could have our cake and eat it too:

          ..  13k  potatoes.txt
        ....   7M  tomatoes.txt
              128  recipe_ideas.txt
    ........   1G  hot_sauce_formula.txt


I'm disgusted, yet intrigued.


That's a clever hack, I like it


>unless you have some fancypants sort which understands them

FWIW GNU sort can sort by human readable units using the -h option.


I really want to know what the deal with hot_sauce_formula being 1G is. That must be one hell of a hot sauce.


If you want to see the largest file, wouldn't you want to sort it by size anyway?


You would, but you would have to run `man ls` to figure out how to do that. That's a showstopper.


Or...

    alias bff='ls -S | head -1' # biggest fscking file


> Most people who work with nix systems work on many systems

[citation needed] Lots of people using macOS and even Linux without being server administrators.


While there has been a influx in command line usage due to mac adoption (has actually been flat for a few years now) most people who find their way to a terminal at some point or another will find their way to ssh.

Also just because you have access to many systems it does not make you a server administrator. I have access to tens of thousands and I am not a system administrator.

Over the years of working with Linux the one thing I have learned that saved me many times and made me productive was to learn the defaults and use the tools that you will most likely find on all systems. If you don't you will find your self bumbling around and feeling lost if you ever log into a system that is missing your favorite modification / customization.


This is the exact reason I have held off on fully switching to something like zsh or fish as well. I have a few thousand servers and basically the only guaranteed thing is that they will have some version of bash or at least sh installed.


We shouldn't need complete backwards compatibility on a command that is completely new, surely? That would limit the amount of improvement that could be made dramatically.

Also, as a side note, why do you enjoy using machine readable file sizes over human readable? The latter, as chosen by their name, are meant to be easier to use for humans.


twic, replied to my original post and I think he does a good job of showing why the machine readable is preferred -- and why human-readable is not actually easier for humans.

I would also like to add to the case twic showed that often I am using ls to see if a file is growing. In human-readable format hides the actual size and rounds -- it could move 200 megs or more before the human-readable output is updated from 1G to 1.2G.

To address why backwards comparability is needed is because of muscle memory. Its not likely that this tool will be on every system I use. I don't want to have to think about what system I am on and what command I need to run. It would be nice to also be able to alias it to 'ls' as ls is way faster to type than eax -- all on the left hand makes it MUCH slower -- although I am sure there will be those who say different -- but they are wrong.


> > For example, exa prints human-readable file sizes by default (when would you not want that?)

When its being used as part of a script.


Parsing ls is a pain anyway, using "stat --printf=%s" is much better in scripts, in my opinion.


I think for scripting just using stat makes lot more sense than exa (or ls).

Of course alternatively exa could aim for that lovely ls-style experience and vary its output depending on isatty(), switching between human-readable and absolute numbers.


Operative word: by default. If you want the bytes value, you can ask for it (-B).


But a length in bytes is even better than human-readable: it's a graph (technically a histogram), so it can be scanned, which is even faster than reading. It's far faster to identify the smallest or largest file in a directory with standard ls. There are some times when I do want human readable, but then I typically want to specify the units, so I see everything in megabytes.


Exactly - it's a logarithmic scale bar chart!


What you are looking for is `ls -S` and `ls -Sr`


It doesn't support LS_COLORS, unfortunately.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: