Live data from Hacker News

Exa: An alternative to Ls

the.exa.website

81–90 of 105 posts

Re: Exa: An alternative to Ls

#81
post #36

The main thing I use Exa for is as a better "tree": et() { exa -alT --git -I'.git|node_modules|.mypy_cache|.pytest_cache|.venv' --color=always "$@" | less -R; } alias et1='et -L1' alias et2='et -L2' alias et3='et -L3' Exa is great for this because it shows file details along with the tree hierarchy. (I have to manually specify a bunch of git-ignores because Exa's git ignore support doesn't work properly.)

Combine it with fzf and you can choose the depth level dynamically:

  tree: aliased to echo '2\n3\n4\n5' | fzf --preview='exa -l -T -L {} --git-ignore' --reverse --preview-window down:99% --bind 'j:down,k:up,q:cancel,enter:cancel'

Re: Exa: An alternative to Ls

#82
These new tools are neat, but because ls, tree, git have most of these features it has been tough to talk myself into using exa.

One minor thing that bugs me about ls however, is the date display. I'd like iso 8601 for old dates, with a human-readable date for recent changes. Currently I have this:

    -rw-rw-r--  1 foo foo   37  2016-03-28  9:14 .Xmodmap
    -rw-------  1 foo foo 496k  Wed Oct 27 14:27 .xsession-errors
Via `ls --time-style=`, but the cutoff between the two styles is hard-coded to something like six months. I'd prefer a week or so, but not an option. I asked on the mailing list but no action. Can exa or another tool be configured to use two date formats with a week in the past cutoff?

Re: Exa: An alternative to Ls

#84

I've been using lsd[0] as my ls replacement for a while. I like that it has a config file for defaults, so I don't have to change a bunch of aliases when setting up a new system. 0: https://github.com/Peltoche/lsd

I switched to LSD from Exa as soon as I realized that Exa wasn't a ls drop-in replacement -- it's been great so far.

Re: Exa: An alternative to Ls

#85
post #78
post #69

Earlier quoted context omitted.

This is a basic flaw in the design of unix. The user interface is coupled to the implementation. To accomplish a task, you don't describe the task - you write the name of a program that executes that task. Once a program is named, no other program can be named that ever again. Imagine if programming languages worked that way.

I don’t understand the programming languages analogy, can you elaborate? One way to interpret that is “s/program/function, class or module/g“, but that sounds strange to me.

That was indeed the thrust of the analogy. Basically, we try to design programming languages so that the interface is decoupled from the implementation. A function should have an intuitive, descriptive name that reflects what it achieves, free of such terrestrial concerns as who wrote it, and when, and whether a different person decided to fix a bunch of bugs in it. But commands in Unix exist in a single-layer, permanently immutable namespace. Someone wrote the canonical 'top' once upon a time and now all evolutions on the concept must use names like "htop" and "vtop" and "gtop" and "ptop". By 2121 we'll have exhausted that namespace too, and be on to "aatop", "abtop" etc.

Good interface design is stable, even as the backend tech improves. Both a go-kart and the NASA crawler-transporter have steering wheels, because the wheel is an affordance for the human, not the machine. But on a Unix system, there's huge churn in how to do things - usually for no better reason than that it would break a bunch of stuff to change how the old way works, so better to simply add a new way. Someone wrote an improved version of grep - does that mean we get grep v2? Nope, we get "ripgrep", and old grep stays permanently...

The worst of it is, that namespace doesn't even guarantee anything! It would at least be some consolation if 'ls' worked identically on every system, but alas...

Re: Exa: An alternative to Ls

#86
post #69

I wish the authors thought a little bit more about the actual physicality of typing out commands. `exa` on a QWERTY keyboard is typed on one hand, across three rows, and with the weakest fingers. I guess I could put this into muscle memory, but I expect an `ls` like command to be ergonomic to some degree and I see myself making a lot of typos.

This is a basic flaw in the design of unix. The user interface is coupled to the implementation. To accomplish a task, you don't describe the task - you write the name of a program that executes that task. Once a program is named, no other program can be named that ever again. Imagine if programming languages worked that way.

aka "lacks namespaces"... but it isn't so. The namespaces are paths and they're "linked" by $PATH. /usr/local/bin is a namespace. Is it guaranteed to be a fully qualified namesake? No. But your sysadmin (now Docker) is in charge of that. You can plan a system that forces everyone to use fully qualified nameplates, but you can't force people to use the system. That's why unix/posix/Linux remain the lowest common denominators.. by making fewer assumptions they retain a different flexibility that makes them useful for gluing together the ornery systems designed by all you planners.

Re: Exa: An alternative to Ls

#88
post #85
post #78

Earlier quoted context omitted.

I don’t understand the programming languages analogy, can you elaborate? One way to interpret that is “s/program/function, class or module/g“, but that sounds strange to me.

That was indeed the thrust of the analogy. Basically, we try to design programming languages so that the interface is decoupled from the implementation. A function should have an intuitive, descriptive name that reflects what it achieves, free of such terrestrial concerns as who wrote it, and when, and whether a different person decided to fix a bunch of bugs in it. But commands in Unix exist in a single-layer, perma…

Interesting but there's no alternative presented. Any large software project typically has a fixed api that can't be drastically changed due to backward compatibility.

No reason to tie it to Unix either, other than it being ubiquitous.

Re: Exa: An alternative to Ls

#89
post #80
post #36

The main thing I use Exa for is as a better "tree": et() { exa -alT --git -I'.git|node_modules|.mypy_cache|.pytest_cache|.venv' --color=always "$@" | less -R; } alias et1='et -L1' alias et2='et -L2' alias et3='et -L3' Exa is great for this because it shows file details along with the tree hierarchy. (I have to manually specify a bunch of git-ignores because Exa's git ignore support doesn't work properly.)

Wanted to add: I realized that my function above doesn't fully show how I use it. I recommend setting your $LESS to include -F so that by default it doesn't leave pages of output in your scrollback. That way you can get a quick tree, scrollable/searchable in your pager, and then don't lose your shell context. FWIW, my $LESS is: export LESS='-iMFx4 --mouse' # smart-case, status bar, quit 1 screen, 4sp tabs Also should…

Thanks for the "less -F" tip! I didn't know we could do that, and I'll definitely find it useful.

Re: Exa: An alternative to Ls

#90
post #63
post #32

Earlier quoted context omitted.

> little bsd differences have been driving me nuts since I took a job that forced me into a MacBook, but these tools solve that issue and are easy to install with Homebrew. I'm in the same boat as you - I love the the rust-based CLI tools. I would also recommend installing the GNU coreutils via homebrew ( https://formulae.brew.sh/formula/coreutils ). This lets you run the GNU coreutils by prefixing them with a `g`, l…

There’s a way also to remap the gnu coreutils to their normal commands without the g prefix. I did it a while ago but I can’t recall exactly how…

Brew will tell you how when you install the package.
Post reply on HN