Live data from Hacker News

Eza: A modern, maintained replacement for ls

github.com

241–250 of 250 posts

Re: Eza: A modern, maintained replacement for ls

#241
post #121

One pet peeve of mine is "human readable dates", especially for a directory listing. If I'm scanning for something I copied into a folder yesterday amongst other things, I don't want everything to show "1 day ago" if I'm looking for something I did around 11am. I want the dates and times. That goes for forums like HN. Show me the date/time and also "7 hours ago" or whatever if you have to. I've never understood takin…

Yeah that is such an amazing anti-feature. And how do you deal with changes? Like, when does 1 day ago become 2 days ago? According to google it becomes two days ago after 48 hours. That means if you look at your phone after 47 hours it will say 1 day ago and you'll be tricked into it happening yesterday. Human readable my ass. Or, you know the specific day because it was the day after your friends birthday or whatev…

I utterly hate this on iOS. Suddenly after an hour or something, you irretrievably lose the time on a notification. There’s not even some fiddly power user way to force it to show you.

Re: Eza: A modern, maintained replacement for ls

#242

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.

Nice tip. What got rid of most of my use of `ls` in fish was running `ls` automatically when you changed directories: function ls_on_cd --on-variable PWD ls end

A word of a warning if you have folders with _a lot_ of files.

Re: Eza: A modern, maintained replacement for ls

#243

Earlier quoted context omitted.

Well it will definitely help with caching. You only need to update the article every year or so.

That's still more than just using an exact date that never needs to be updated. Also that seems like something you would do client side anyway. ie. you send a timestamp that never changes and then have the client convert it to "X years/days ago."

Most people render the html on the server side and then you can just cache it wholesale.

You could cache the page itself or even the article itself (I'm not talking about browser cache, I'm talking about caching on the web server).

The idea being that you don't have to keep rendering or even hitting your DB for the content you just have a html fragment that you create once and cache and then serve. You'll only need to rebuild the content when the date expires so when "one year ago" becomes "two years ago" .

Re: Eza: A modern, maintained replacement for ls

#244
post #235

Why `ls` replacement needs kerberos and ssh? ldd /usr/bin/eza linux-vdso.so.1 (0x00007f5238f5e000) libgit2.so.1.7 => /lib/x86_64-linux-gnu/libgit2.so.1.7 (0x00007f5238cfd000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5238cd0000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5238bee000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5238a09000) libgssapi_krb5.so.2 => /lib/x86_64-linu…

That's a lot of dependencies for ls of all things

Re: Eza: A modern, maintained replacement for ls

#245
post #79

Earlier quoted context omitted.

fwiw we're glad we're scaring people like that away :p

You really shouldn't. You're adding to the stereotype that Rust developers are insufferable and not to be collaborated with. Scaring away good developers from your projects is a bad thing, not a good thing.

[flagged]

Re: Eza: A modern, maintained replacement for ls

#246
post #44

Earlier quoted context omitted.

Nice tip. What got rid of most of my use of `ls` in fish was running `ls` automatically when you changed directories: function ls_on_cd --on-variable PWD ls end

Oh cool idea! But gosh I think I would hate that.. I typically know what files are in directories that I'm working in, and usually care more about the output of previous commands I've run. I feel like this would teach me to never change directories

When I want to cd I usually don't type cd. I use zoxide which is a modern autojump.

In fish shell you can also just type the directory path and press enter and it will change the working directory.

Re: Eza: A modern, maintained replacement for ls

#248

Earlier quoted context omitted.

Bash users: FYI you can bind shortcuts like this, too. I have my right hand home row keys bound to __bash_ctrl_n() (for e.g.), and various tools in my dotfiles override these functions (git, if installed, sets up __bash_ctrl_e() to run git status and git log).

Neat. Can you share the source of any of the functions you've bound to some of your keys?

Apologies for the slow response. They're not really interesting:

- ctrl+j => equivalent of 'ls -la' using exa/eza

- ctrl+k => git status followed by git log showing only current branch's commits (vs. tracked)

- ctrl+l => sometimes I'll manually bind this to 'git reset @~'

- ctrl+; => thinking I'll use this for calling fzf through my wrapper which sets up hotkeys for either `cd`/`$EDITOR`-ing the selected item

Point is to reduce typing of the commonly-used commands.

Somewhere in my shell profile/rc setup (I'm on Workman, not Qwerty, hence NEOK instead of JKL;):

    bash_functions=(
      "__bash_ctrl_n"
      "__bash_ctrl_e"
      "__bash_ctrl_o"
      "__bash_ctrl_k"
    )
    
    for bash_function in "${bash_functions[@]}"
    do
      if ! type -t "$bash_function" 1> /dev/null
      then
        eval "$bash_function() { echo \"$bash_function(): This function should be overridden/aliased\"; }"
      fi
    done
Then in my .bashrc (Note the leading space prior to `__bash_ctrl_x` - with Bash's `HISTCONTROL=ignorespace`, these keybinds won't pollute your history):

    bind '"\C-n": "\C-u __bash_ctrl_n\C-j"'
    bind '"\C-e": "\C-u __bash_ctrl_e\C-j"'
    bind '"\C-o": "\C-u __bash_ctrl_o\C-j"'
    bind '"\C-k": "\C-u __bash_ctrl_k\C-j"'
Then in my app-specific configs/dotfiles:

    __bash_ctrl_n() { git status; git log ..; }
Bonus: these Bash bindings can be cool for little QoL tricks, e.g. Ctrl+Y to rerun the last command with sudo.

    bind '"\e\C-y": "\C-usudo !! \C-j"'
Other good ones:

- Append `--help | $PAGER` and run

- Rerun last command and pipe into $PAGER (some terminals support viewing last command output in a pager without re-running it, e.g. Kitty)

Hope that helps.

Re: Eza: A modern, maintained replacement for ls

#249

One pet peeve of mine is "human readable dates", especially for a directory listing. If I'm scanning for something I copied into a folder yesterday amongst other things, I don't want everything to show "1 day ago" if I'm looking for something I did around 11am. I want the dates and times. That goes for forums like HN. Show me the date/time and also "7 hours ago" or whatever if you have to. I've never understood takin…

The same I feel, so I didn't bother to print human readable dates in my open source mlops project. xvc file list[0] prints times in the same format even if it changed a minute or a year ago.

[0]: https://docs.xvc.dev/ref/xvc-file-list

Re: Eza: A modern, maintained replacement for ls

#250

There is also 'lsd' but I still prefer eza. For everyone interested there is a lot of modern command line tools I nowadays prefer over the old stuff: bat - cat with highlight difftastic - better diff gdu - ncdu for ssds (disk space analyser) zoxide - modern cd fd - find alternative rg - ripgrep (grep) fzf - fuzzy finder jless - json viewer with mouse folding dra - download and install release assets lazygit - git TUI…

> fd - find alternative > rg - ripgrep (grep) NOTE OF WARNING: BY DEFAULT these ignores anything included in your `.gitignore` folder. So if you think it is a straight find replacement, you'll likely be surprised. fd discussion here[0] Just make sure that when recommending people these tools that this is clear because if they don't read the docs (lol who does) they'll miss this part. This is a pet peeve of mine. I wi…

> I wish the people that make these replacement coreutils (and others) would leave the defaults as very similar to the original tool. I do really like the new functionalities but if you market it as "an alternative" ("It is a simple, fast and user-friendly alternative to find") then they should respect the defaults of the original because it reduces new user surprise. I mean aliases exist... So it is better to have in your ~/.${SHELL##*/}rc file to have `alias fd='fd --ignore'` than `alias fd='fd --no-ignore'`.

I never marketed ripgrep explicitly as an "alternative." But it would be entirely appropriate to do so. An "alternative" does not mean "has exactly the same behavior." You're confusing that with, "drop-in replacement that is bug-for-bug compatible."

If people such as myself working on these new tools had your mindset, then there would literally never be any room for improving the default behavior. Which just seems like a wild position to stake out to me. Defaults really matter, and other than performance, ripgrep's default ignore behavior is far and away the thing people consistently remark as their favorite feature.

Post reply on HN