[HN Gopher] Exa - A Modern Replacement for ls
___________________________________________________________________
Exa - A Modern Replacement for ls
Author : gilad
Score : 238 points
Date : 2021-12-18 22:48 UTC (1 days ago)
(HTM) web link (the.exa.website)
(TXT) w3m dump (the.exa.website)
| ozzythecat wrote:
| I used exa for a short while but switched back to using ls. Maybe
| I was using it wrong, but with my iTerm2 and ohmyzsh profile, I
| already had colors set the right way, and I couldn't really see
| any advantage to using exa.
| Aloha wrote:
| This looks great, I submitted a feature request to also show
| permissions in Octal, which is one of the 'missing features' I've
| always considered to be present in ls.
|
| It's always bugged me that chmod takes octal, but all of the
| other tools output a more human readable format, and its up to me
| to do the mental math in my head to convert - I dont know about
| you, but I'm bad at doing octal in my head ;-)
| Hendrikto wrote:
| chmod also takes human readable notation as input, as in
| chmod g+w,o-rx ...
| Aloha wrote:
| often I need to match permissions on something already there,
| so I'm trying to go "uhhh, its, rwxr-xr-x what does that
| translate to again?"
| tgv wrote:
| One octal digit comprises three bits: read, write and execute,
| with values 4, 2, and 1. Add them and you get the octal digit:
| 7 is everything permitted, 4 is read-only. The three octal
| digits represent permission for owner, group and the rest. So
| stay way from 777.
| I_complete_me wrote:
| I use the idea of the binary numbers from 1 to 7 as an aide
| memoire: rwx
|
| 0 000
|
| 1 001
|
| 2 010
|
| 3 011 --> -wx
|
| 4 100
|
| 5 101
|
| 6 110
|
| 7 111
| Aloha wrote:
| I set permissions on something just infrequently enough that
| I dont have that as muscle memory, and often I need to match
| permissions on something already there, so I'm trying to go
| "uhhh, its, rwxr-xr-x what does that translate to again?"
|
| Also, frankly, the computer _is_ a calculator, why not have
| it act as the calculator _for_ me, and tell me what the
| permissions already are, I can read the octal permissions and
| know what they mean.
| poewrljaf wrote:
| chmod --reference=file_with_permissions_i_want.txt
| file_whose_permissions_i_want_To_change.txt
| Aloha wrote:
| you learn something new every day!
| mixmastamyk wrote:
| That's what GUIs are for, this exact use case.
|
| The sibling with the reference param is a great option as
| well, if you can remember it.
| everforward wrote:
| I may just work with file permissions more than most, but I
| prefer the octal for its density. It's easy to tell my coworker
| the permissions are wrong, it should be 755 not 644. It's a lot
| harder to convey that they should be rwxr-xr-x instead of rw-r
| --r--.
|
| I also find diffing easier. 767 is different from 777, which is
| easy to see. It's harder to scroll in ls and find the one
| that's rwxrw-rwx rather than rwxrwxrwx.
|
| The last one is that the human format is legitimately awful at
| calling out setuid/setgid, and those are really important to
| notice. How many people are going to notice that 'rwxr-sr-x' is
| different than 'rwxr-xr-x'? The equivalent octal is 2755, which
| is very noticeably different from 755 (or 0755 if you prefer).
|
| I'm not opposed to having the option, but I do think there are
| advantages to octal. Those advantages do probably wane if you
| don't have to deal with some of the more arcane permission
| sets.
| CyberShadow wrote:
| I'm finding the website much more exciting than the tool itself.
| Which is not a criticism of the tool - the website is just really
| neat!
| fareesh wrote:
| I find that if there is even a hint of latency with these types
| of tools it puts me in a foul mood
| ModernMech wrote:
| IMO if you want to replace ls it has to be a 2 character command.
| I can type ls super fast with two hands. exa is really awkward to
| type.
| creamytaco wrote:
| alias
|
| .. but exa is not backwards compatible with ls OOPS
|
| Which is why I stick with ls (and grep instead of rg and
| coreutils instead of shiny rust equivalent), I can't deal with
| the cognitive dissonance that arises from these differences.
| incanus77 wrote:
| I aliased `ls` to it... I don't know how long ago. It's been
| great.
| nsonha wrote:
| what can break when you alias standard system command name to
| some random program downloaded from the internet.
| omgmajk wrote:
| I have 'lsd -al' aliased as 'l', it works fantastic.
| chdlr wrote:
| if some color and additional hints is all you need, this may be a
| competitor:
|
| alias ll='ls -lahF --color=auto'
| enobrev wrote:
| This is the first alias I create on any os I use daily.
|
| Although I order the switches as `halF` as it's easier to
| remember for quick one-off use on servers (and containers).
| It's practically muscle memory for me now.
| tgv wrote:
| I must be one of the few, but I rarely like color output. And
| then some throw in underline or bold, but in e.g. ls (or exa)
| almost none of the make-up adds information, yet everything
| shouts for attention. I turn most of it off, rather than on.
| gkfasdfasdf wrote:
| The automatic git status is the killer feature of exa for me.
| Makes it easy to see what files have been changed, what's
| ignored. etc.
| RMPR wrote:
| I used to think exa was a good ls replacement, but I found out
| that it's significantly slower than ls[0]. Heck, it's even slower
| than lf[1]. Quite frankly I didn't know what to think, but I
| removed the alias ls=exa.
|
| 0: https://asciinema.org/a/454216 vs
| https://asciinema.org/a/454217
|
| 1: https://asciinema.org/a/454213
| mikkelam wrote:
| That does seem rather bad, I wonder what is causing such shitty
| performance?
| kreetx wrote:
| Make it work, make it correct, make it fast - perhaps they
| haven't reached phase three yet?
| miohtama wrote:
| From the documentation
|
| > Here's an example. exa, by default, runs the stat system
| call on every file it encounters. This requires communicating
| with the storage device or hard disk to get that file's type
| and permissions, which determine how that file gets coloured
| and displayed on screen. The system call, which may have been
| expensive in the days of time-shared computers and slow
| connections, is still not free, but is extremely cheap. The
| extra information is worth the minuscule increase in
| processing time.
|
| For 100% - ~3 use cases the performance difference does nit
| matter as a human is unable to react in milliseconds. You can
| always fallback to ls.
| xxpor wrote:
| I'm willing to bet it's the fact that they're in a git repo.
| exa checks git status iirc, and of course ls doesn't. I'll
| try to repro it.
|
| Edit:
|
| Hmm, interesting. Certainly a lot slower, but not enough that
| I'd really notice unless I was doing this constantly:
|
| time ls
|
| real 0m0.228s
|
| user 0m0.145s
|
| sys 0m0.082s
|
| time exa
|
| real 0m1.209s
|
| user 0m1.124s
|
| sys 0m0.084s
| esprehn wrote:
| Yeah at first I thought maybe the git feature but in the
| demo they're not passing --git. See also: https://github.co
| m/ogham/exa/issues/367#issuecomment-4285909...
|
| ls taking seconds and exa taking 13 minutes :(
|
| Their website says it's as fast as ls because they do
| things in parallel but it doesn't seem to actually be as
| fast as ls in small or large usage.
|
| I'd also say 200ms -> 1.2 seconds is very noticable.
| xxpor wrote:
| Based on perf report, the latest stable version of exa is
| spending >99% of its time doing grid stuff. I pulled the
| repo from git, and using the latest master commit, it
| appears to have a huristic to not bother with the grid
| when you have lots of files. Now the times are a lot
| closer. (redirected stdout to /dev/null since otherwise
| the vast majority of the time would simply be outputting
| to the shell)
| [user@anarchy:~/exa_test]$ time ../exa/target/release/exa
| >/dev/null
| ../exa/target/release/exa > /dev/null 0.05s user 0.07s
| system 99% cpu 0.122 total
| [user@anarchy:~/exa_test]$ time /bin/ls >/dev/null
| /bin/ls > /dev/null 0.03s user 0.01s system 99% cpu
| 0.048 total
| xxpor wrote:
| >I'd also say 200ms -> 1.2 seconds is very noticable.
|
| One of those things that if I'm looking for it, I'd
| notice but otherwise...
|
| I deal with so many slow CLI tools daily that it wouldn't
| even register.
| lilyball wrote:
| Exa does colors and other stuff by default. I would wager
| it's stat()ing every file and ls isn't.
| johnisgood wrote:
| Wow. This is very slow. If the only feature here is that it
| supports colors (so does ls, by the way) or extra information
| (so does ls, by the way), all while being much slower, then I
| do not see the point in replacing ls with this.
|
| Someone mentioned that you can just do: alias
| ll='ls -lahF --color=auto'
| leephillips wrote:
| exa does (or can do) more than that. Git information, for
| example; and more fine-grained output control.
| netizen-936824 wrote:
| Does the slowness really matter for most use cases though?
| NikolaNovak wrote:
| I suppose it depends on a person and situation. Significant
| amount of my lists end up an overfull directory of logs or
| traces or whatevers. Basic utilities used daily (hourly?
| Minutely?) need every inch of speed eeked out.
| robbedpeter wrote:
| Helper scripts using ls can involve lots of items and
| recursion, so the slowness can go exponential. A serious
| replacement candidate needs to be as fast or faster.
|
| Maybe a performance based execution of exa could be crafted
| that ignores some of the eye candy or whatever is sucking
| up the cycles.
| nexuist wrote:
| ls is probably one of the most used command line utilities,
| up there with `cd` and `echo`. It will be very easy to
| notice performance degradation.
| johnisgood wrote:
| Yes, it matters a lot. These tools are supposed to be fast.
| I use them all the time, and if there is a tool that does
| the same but one takes 1 sec and the other one takes 30
| seconds, then of course I am going to pick the faster one.
| netizen-936824 wrote:
| I do as well, but I guess none of my use cases have
| involved either listing absurd amounts of files nor have
| I used ls or exa in any scripts. I do use exa _and_ ls
| (usually on systems where I don 't have exa installed or
| when I forget to type "sl" instead) The difference has
| been barely noticeable for me
| tills13 wrote:
| I'd say this is a situation where you should use a tool that's
| appropriate for the job.
|
| Listing 70k files without greping or piping into another
| process is something you are probably not going to ever do. exa
| seems very good for the average case.
| smokey_circles wrote:
| I'm not sure I'm following. Listing 70k files was a
| benchmark. It would take you 10x the time to use 'exa | grep'
| but grep might just filter out the item you're looking for
| during execution (not certain if grep is reading the pipe as
| it is output or waits for execution to complete first). exa
| still needs 7 seconds to check all files. ls only needed a
| tenth of that
| tills13 wrote:
| I'm saying you would use `ls | grep ...` in situations
| where you're transforming the output but use `exa` when you
| specifically care about the files or their metadata.
|
| That is, use ls when you you don't care about the direct
| output of the list file command, use exa when you do.
| authed wrote:
| the --tree feature is incredibly slow
| elliotlarson wrote:
| I find comments like "I've been using <the tool> forever and
| never noticed <this> problem" a little annoying. But, I fall
| into this camp here. I'm not trying to dismiss other people's
| criticism that the slowness has had a negative effect on their
| workflow. But, here it goes, I use exa as my ls replacement and
| I've never even noticed it was slow. And, for me, the chief
| value really comes down to exa's color coding of results. It
| helps me see the information more easily which I feel has a
| cumulative effect of speeding up my workflow.
| bool3max wrote:
| That is not at all the behavior that I am observing on my
| system:
|
| "time command ls -lR -color=always": 898 millis
|
| "time command exa -lhgR --icons": 638 millis
|
| This is in a directory of roughly 17k files of varying
| filetypes. Exa also outputs underlines and icons.
|
| ---
|
| Admittedly if I create 80000 arbitrary extensionless files "ls"
| takes around 700 millis while exa takes around 1000 millis, but
| still the performance difference is nowhere near what you
| demonstrated.
|
| I don't know what job you're doing that requires "ls"-ing >20k
| files, but on my system there seems to be no performance
| penalty before an uncertain, unachievable threshold.
| kkirsche wrote:
| Both exa and lsd[1] are amazing ls replacements. I personally
| stuck with lsd as it was easier to alias to ls but great work by
| exa.
|
| 1. https://github.com/Peltoche/lsd
| UkiahSmith wrote:
| I prefer lsd over exa because the flags are more compatible
| with standard ls
| zingplex wrote:
| I think that's what OP means by "easier to alias"
| varenc wrote:
| Agreed. I gave up on exa because `ls -tr` doesn't work.
| thanatos519 wrote:
| I tried both and ended up with lsd, but both have my favourite
| feature which is the icons via Nerd Fonts.
| otterz wrote:
| It's always nice to have more alternatives to traditional unix
| tools/commands, especially these new tools written in Rust that
| are popping up.
|
| The website claims exa is a "modern replacement for ls", but
| unlike ls it doesn't seem to follow the "do one thing" unix
| concept - the git integration is one reason why. I'm not sure the
| git integration is a good idea.
| lilyball wrote:
| IDE file trees these days often show git status. Why not
| terminal file lists?
|
| The problem with "don't do that" is you can't add it on after
| the fact using another tool, like you can with e.g. sorting.
| You have to run a separate command and correlate the output
| yourself.
|
| Personally I don't rely on exa's git support (I never even
| remember it's there) but it seems potentially valuable, and now
| that you've reminded me about it I plan on looking into how to
| integrate it into my workflow.
| w-j-w wrote:
| exa isn't a scripting tool designed to be tied together with
| other scripting tools that also only do one thing. I think that
| it's probably better to consider the end user experience rather
| than the catchy parts of a design made decades ago for an
| entirely different context.
| lancebeet wrote:
| Does ls really follow the unix philosophy though? GNU ls can
| show file permissions, modification timestamp, author, size,
| sort the listing etc. It does a lot more than a simple
| directory listing. We've just gotten used to its current extra
| functionality.
| bayindirh wrote:
| File permissions, inode number, dates associated with a file
| are all features of the files, and it's natural to be a part
| of a directory/file lister.
|
| One can always create separate tools for all the extra
| functionality in ls, however without the file name,
| associating all the information would be hard, so if these
| properties need a file name to be meaningful, why not add it
| into a single tool?
|
| It's not like ls is changing group/owner, mode, or modifying
| timestamps or doing filesystem dependent things. It just
| lists files, with a bunch of extra information, if you want.
| alerighi wrote:
| File permission, timestamps and other stuff are things that a
| directory listing program should show you.
|
| Regarding sorting, one can say that you can pipe the output
| to sort. True, but less efficient. Most filesystem
| implementation already give you the directory listing sorted
| in alphabetical order. So ls can be aware of that cases and
| simply give you the sorted list as returned by the operating
| system, in case one of that filesystem is used, without
| wasting time sorting an already sorted list.
| Someone wrote:
| Sorted in _some_ order that may be similar to that of the
| current locale, but isn't necessarily exactly the same.
|
| I think it is highly likely they will be somewhat different
| because file systems that order directory entries
| alphabetically (1) either
|
| - can't keep track of Unicode version updates (if they did,
| old disks could end up having entries stored out of order),
| so they have to guess how entries for Unicode code points
| assigned at some future time will sort. I don't think that
| can be reliably done.
|
| or
|
| - have to store some data on disk to tell users what the
| ordering is (original Mac HFS did something like that by
| storing the code page to be used to interpret the byte
| sequences of file names as characters on disk). That would
| mean _ls_ would have to get that data from disk, and only
| if it matches the current locale, could skip the sorting
| step.
|
| There also is the risk of bugs in the implementation that
| can't be fixed once millions of disks exist (the original
| Apple HFS file system had a bug there).
|
| There's also the possibility of traversing mount points
| during a recursive ls or even of union mounts
| (https://en.wikipedia.org/wiki/Union_mount) during non-
| recursive listings, which means the on-disk order can
| change during listing.
|
| = I doubt _ls_ uses this trick (I haven't checked any _ls_
| sources, though, so corrections welcome)
|
| (1) that in itself is a weird idea, as, on Unix, file names
| are byte sequences, not character strings. That's a
| different subject, though.
| redleader55 wrote:
| You can get all that info with a single stat() syscall.
| Looking into git for more info, is significantly more
| complicated.
| gjsman-1000 wrote:
| If all the coreutils on Linux and Mac had color coding and used
| more "sane defaults"... I'd be so happy.
| nrvn wrote:
| There is a cohort of "replacements" to traditional tools.
|
| Check here: https://github.com/ibraheemdev/modern-unix
|
| Some of them are great, some are opinionated.
| typon wrote:
| I wrote an interactive sed replacement:
| https://github.com/typon/tabdeeli
| vzaliva wrote:
| I think the most important feature of `exa` is not what
| additional information it could show, but rather what it _does
| not_ show. It makes moden ergonomic choices presenting directory
| information using omissions, abbreviations, and colours.
| lilyball wrote:
| Pro tip: if you use fish, don't alias ls=exa, instead set an
| abbreviation (abbr). This way you can keep typing ls at the
| command line and it will turn into exa, but it won't interfere
| with other functions.
|
| I'm not sure if there's an equivalent for bash/zsh.
| greatgib wrote:
| <<exa queries files in parallel, giving you performance on par
| with ls.>>
|
| I think that this is bullshit! Maybe the author thinks that it is
| really the case, probably tricked by the language, because using
| async, but in the end, the syscall to read folders is
| synchronous...
| ericbarrett wrote:
| The syscall to list a directory is synchronous, but the follow-
| up stat calls to read file attributes (type, permission,
| attributes, size) are done one file at a time, so there are
| opportunities for parallelization.
|
| Incidentally, this is why ls without colors or type symbols
| (-l, -F, --color, and so forth) is a lot faster: it doesn't
| have to query every file to find out what it is in order to
| display the color/symbol/permissions/etc. Handy if you're on a
| slow networked file system and just need to see names.
| userbinator wrote:
| I don't see how parallelism could work with stat() in
| general, since the OS has to keep the FS structures
| consistent and ultimately there is only one disk to read
| from, unless you have RAID.
| edwintorok wrote:
| It would be better if it used fstatat instead of regular stat
| calls. On a deeply nested directory it can make a difference
| (e.g. a single-threaded 'find' easily beats a parallel 'fd'
| with warm caches on my machine, 'exa' could similarly
| benefit)
| vidarh wrote:
| It's not reading the folders that is the main slowdown in ls
| (and exa and similar) for more complex lists, but all the extra
| work done per file.
|
| ls and similar can (and do) requests the files in batches, so
| if the directory has enough files for speed to matter you can
| request one and then asynchronously query whatever additional
| information you need.
|
| If you only want the filename and whether it's a directory,
| device or file, then you won't do much better than ls, but you
| also likely won't do much worse.
|
| But the moment you want e.g. filesize you need to stat() files.
| That too will be the same whether or not it's ls. But exa also
| does things like check git and _that_ will add significant
| overhead that they may or may not alleviate by doing it in
| parallel.
| zopa wrote:
| I always find pitches like this a little obnoxious:
|
| > You list files hundreds of times a day. Why spend your time
| squinting at black and white text?
|
| Uh, `ls` has colors, if you know how or some benevolent distro-
| maintainer did.
|
| Now there's a ton of value in sane defaults and cutting out cruft
| and targeting specific use-cases, so not here to criticize the
| tool, at all. Just the marketing. Why not talk about what's
| actually special and different about it?
| bayindirh wrote:
| When the motivation about replacing something is just
| colors/icons and other fluff, I just don't consider the tool
| worth it.
|
| Also, changing default tools are fine for a single system, but
| when you're managing many, and with a team, that's a big no no.
| thebeardisred wrote:
| Thanks for writing the bulk of my comment for me. :)
|
| The thing I would add is that tools like this cater to
| introductory users, not power users. They're for the person who
| tweaks every cosmetic default to the point where they _need_ a
| setup of "dotfiles" to be functional.
|
| Meanwhile, tools like this often skip over important
| implementation details like extended file-system attributes.
| userbinator wrote:
| I actually prefer my ls output to be monochrome, and the first
| time I encountered a coloured one I turned it off since some of
| the colours were nearly unreadable (who thought dark blue and
| gray on black was a good idea?)
| jagger27 wrote:
| That's not ls's fault. That's just your terminal's colour
| scheme.
| Shadonototra wrote:
| i did a quick test
|
| exa -l vs ls -l ./exa -l /home/_/Downloads
| 0.00s user 0.01s system 131% cpu 0.010 total ls
| --color=tty -l /home/_/Downloads 0.00s user 0.00s system 93% cpu
| 0.003
|
| exa uses +40% cpu usage and is slower.... not good
| medv wrote:
| I recently wrote ls + cd replacement myself:
| https://github.com/antonmedv/llama
|
| It's a TUI with fuzzy searching, which helps a lot at navigating
| in complicated file systems.
| tomxor wrote:
| Similarly, i'm really enjoying broot recently, which isn't quite
| just a replacement of ls which I still use, but it's a great way
| of getting directory listings / file listings in one shot, and to
| be able to launch other stuff form there.
|
| I used to use nerdtree in vim, now I just launch vim from broot,
| which feels like the right way around, because I can use broot
| for lots of different things.
|
| I looks like exa has more colour capabilities though.
| tcoff91 wrote:
| I think that fuzzy finding is a much better way to open files
| than browsing a directory tree.
|
| fzf is an amazing tool for this.
| mgaunard wrote:
| does it have automated paging like git? doesn't look like it.
| lancebeet wrote:
| Can't you just do something like if [[ -p
| /dev/stdout ]]; then ls; else ls |
| less -F -R; fi
| timmytokyo wrote:
| You lose the colors by piping through less.
| eMSF wrote:
| No you do not. Also, unless I'm mistaken, git uses the
| system pager for pagination and that happens to be less on
| almost all modern Linux systems (and many others).
| efdee wrote:
| Peak HN right here.
| CyberShadow wrote:
| I think, except for very large volumes, automated paging is
| inferior to terminal scrollback. It is conditionally modal
| (thus conflicts with muscle memory) and you can't see previous
| output and the paged output at the same time (quitting the
| pager restores the terminal contents). I turned mine off in
| Git.
| faizshah wrote:
| The tree feature itself is worth it:
| https://the.exa.website/features/tree-view
|
| I always install tree on a new nix machine, might try this one
| out.
| dystroy wrote:
| What about a tree which automatically fills the available
| height of the console, while staying balance ? Look at
| https://dystroy.org/broot/tricks/
| faizshah wrote:
| Wow, I haven't heard of this one, thanks for the suggestion
| gonna try this out tomorrow. I usually pipe to less but this
| could be nicer.
| RMPR wrote:
| It's the tree feature that made me investigate the speed of exa
| (see my other comment in this thread) because it was very slow.
| Otherwise I agree, exa is neat.
| wruza wrote:
| Non-positive opinion ahead.
|
| Personally I can't find a use for it. Colors are so vast that I
| can't figure out which means what (and they rarely play nice with
| a custom bg color). And then, _all_ I have to know is whether a
| file is "- >", "*", "/" or "". Tree+git view could be useful, if
| not node_modules, .git and other tree spammers. Of course there
| is an option to ignore, but then my .bashrc grows again while all
| I need in a project dir is covered by git status -s (yes I can
| read these capital letters since svn).
|
| It is modern in a sense of presentation, and I see how it may
| appeal to someone, but not in a sense of ls being old or
| something. It feels to me like a strange tool that does
| everything but nothing specifically, as if someone always wanted
| a nice gui file explorer, but had no courage to admit this
| "lameness".
|
| _Why spend your time squinting at black and white text?*
|
| I usually spend time on colored output trying to read
| blue/lightgreen/etc on #444, and because my b/w tools are
| separated by colored PS1, which emphasizes _important* things
| like hostname, user, cwd, exitcode and puts a newline so that
| each command is lined up and ends with an additional \n. File
| being a green file or a blue dir is not as important as me
| patching a wrong instance.
| infocollector wrote:
| I've been using natls - has anyone compared that with exa? pros
| and cons?
| backoncemore wrote:
| Cool project but no real world use case.
___________________________________________________________________
(page generated 2021-12-19 23:00 UTC)