Live data from Hacker News

Eza: A modern, maintained replacement for ls

github.com

61–70 of 250 posts

Re: Eza: A modern, maintained replacement for ls

#61

I'm under the impression that ls doesn't do very much. I'd expect it to be a small wrapper around libc. This is thousands of lines of rust with emphasis on community building and ongoing development. There seems to be a disconnect between engineering effort and product here which doesn't totally make sense to me. I think I'll stay with ls.

Challenge: which of the letters a to z and A to Z are NOT switches that modify the behavior of ls? I would guess that ls has at least 50 different behaviors based on the switches.

> which of the letters a to z and A to Z are NOT switches that modify the behavior of ls?

For GNU ls: e/E, j/J, V, K, M, O, P, W, y/Y and z are not used

It uses all the other upper and lower case letters, along with digit 1 and has a hand full of long options without a corresponding short one.

Edit: I double-checked the man page, I'm surprised how many are unused, I would have guessed that it uses all of them by now.

Re: Eza: A modern, maintained replacement for ls

#62
post #36
post #23

Earlier quoted context omitted.

If tooling would simply use the Base16 Framework[0] instead of arbitrary colors from “256 color” or “RGB” color modes, this would be much less of a problem: the output would always be displayed with (presumably) readable colors defined by your terminal. [0] https://github.com/chriskempson/base16 [1] https://tinted-theming.github.io/base16-gallery/

As a CLI tool author, I don't understand how I can use base16 to "theme" my tool's output. Can you point to some resources?

It’s the first 16 colors of the 256 set. Most current graphical terminals support the latter, but they only expose the first 16 in their configuration. So using them makes your software completely customizable. I believe the tty console only use the first 8.

Re: Eza: A modern, maintained replacement for ls

#63
post #36
post #23

Earlier quoted context omitted.

If tooling would simply use the Base16 Framework[0] instead of arbitrary colors from “256 color” or “RGB” color modes, this would be much less of a problem: the output would always be displayed with (presumably) readable colors defined by your terminal. [0] https://github.com/chriskempson/base16 [1] https://tinted-theming.github.io/base16-gallery/

As a CLI tool author, I don't understand how I can use base16 to "theme" my tool's output. Can you point to some resources?

I'm not sure if eddyg had a different idea, but I think the following sums it up:

  - base16 is a specification of how different UI elements map to colors [1], and also some tooling, configuration files, etc. to automate setting this up for many different applications.
  - For a user to be able to use base16 with a tool, either:
    - Allow the user to set their preferred colors for UI elements at a semantic level, preferrably in a config file, and even more preferrably in a separate file that can be included into the main config file so that it's easier to automate (i.e. I have a separate `colors.sh` that is loaded in my `.zshrc`).
    - Let the user set their shell colors however they want (presumably using [2]), and use the ANSI shell colors (and a few more) according to the base16 style guide [1]. Some translation between shell colors and base16 colors will be necessary, e.g. base16 says that a language keyword should use the color base0E, which in [2] corresponds to ANSI shell color 13.
My impression is that the base16 specification is not sufficiently general for most tools to implement it in a totally unbambiguous way, but if users can set their own colorschemes with a config file, it's not hard for a user to come up with a base16-approximating colorscheme template file, from which other users can generate a config file that sets a specific base16 colorscheme.

[1]: https://github.com/chriskempson/base16/blob/main/styling.md [2]: https://github.com/chriskempson/base16-shell

Re: Eza: A modern, maintained replacement for ls

#65

Typing eza is a pretty horrible three character combination on a qwerty keyboard. One advantage of ls is it’s a lightning fast set of key strokes. I guess you can alias, but that’s kind of weird (compatibility, etc).

I’ve had eza (and formally exa) aliased as ls, ll and lll since around 2015 and never hit a compatibility issue.

I also have sl installed to encourage accuracy when running it…

Re: Eza: A modern, maintained replacement for ls

#66

My ls usage went down 100% after I switched to fish shell. The built in Alt + l command lists the directory contents. Very helpful! And also results in a cleaner shell history.

For me, there are two principal cases of sorting in `ls` output: alphabetical when I'm trying to find something I don't know/ remember exactly, and mtime-based when I want to see the latest (or oldest) in a group of related files. I don't see how it could work with one shortcut.

Another thing is `ls -l` that's important when I need to understand file sizes and especially how symlinks are set up. Yet another is `ls -ld` which explains details about directories.

All these cases could be made more ergonomic, and maybe partly merged. But I don't see how I could compress them into one type of output that fits all purposes.

(My current fancy version of `ls` is `lsd`, but I still use the built-in `ls` a lot.)

Re: Eza: A modern, maintained replacement for ls

#68
post #14

What's the point, though? You still have to rely on POSIX and / or GNU tools in most scenarios, and if already knowing / using those, then why bother to switch to anything else?

The only time you have to care about GNU tools vs your own preference of tool is when writing scripts to run on computers running some Linux distributions, and per [1] you shouldn’t be using ls for that.

[1]: https://www.shellcheck.net/wiki/SC2045

Re: Eza: A modern, maintained replacement for ls

#69
post #27

Who uses ls anyway? I tab-complete until it lists the files I need. Just kidding. But on a more serious note, why does he claim ls is not maintained anymore?

Of course `ls` is maintained, as a part of your shell or of coreutils.

But `eza` is a variation of `exa`, and the latter is no longer maintained, AFAICT.

Post reply on HN