keep original name exa

[Freed-Wu]

Hey, Why not keep original name exa? There are many programs taken over by community and keep original name. It can give users convenience. Such as they don't need to change the command names of their scripts.

[eggbean]

This would cause a lot of confusion downstream where distro maintainers and users won't know what they have.

[cafkafk]

You can see the original reasoning here, that being: not having permission to do so from the author of exa, ogham.

However, after all this time has passed, and having changed the name so many places, I do think it would be more of hassle.

[cafkafk]

Is it any difference from this situation?

Deleting the repository does free it up and indicates that one is done with it.

If so, can we use its name?

At this point, I think its advantageous for the reasons eggbean outlined. Our codebase has diverged a lot already, and I do think a lot of us have different priorities than exa.

Maybe github official can give some maintainer a higher priority to transfer this repo after contace with github, which can keep all original issues and pulls.

I don't think this is possible without him having named a successor that can present a death certificate. I've personally made such arrangement for eza to increase our bus factor.

[Freed-Wu]

So can we use a different repo name but provide same name of executable program to the hassle to the downstream users' script? I know such BSDcoreutils provide many executable programs with same name as GNU coreutils. and busybox does similar things. Maybe we can name the repo neoexa or exa2, exa-again and provide executable program with same name exa?

[cafkafk]

For now, no. exa and eza also has different behavior, and e.g. the grid bug not being present might break downstream users.

[Freed-Wu]

GNU coreutils/BSD coreutils/busybox also have different behaviors. So I think different behaviors is not a problem?

Updated: Arch linux has provided exa in eza.

$ pacman -Ql eza
eza /usr/
eza /usr/bin/
eza /usr/bin/exa
eza /usr/bin/eza
eza /usr/share/
eza /usr/share/bash-completion/
eza /usr/share/bash-completion/completions/
eza /usr/share/bash-completion/completions/eza
eza /usr/share/fish/
eza /usr/share/fish/vendor_completions.d/
eza /usr/share/fish/vendor_completions.d/eza.fish
eza /usr/share/licenses/
eza /usr/share/licenses/eza/
eza /usr/share/licenses/eza/LICENSE
eza /usr/share/man/
eza /usr/share/man/man1/
eza /usr/share/man/man1/eza.1.gz
eza /usr/share/man/man5/
eza /usr/share/man/man5/eza_colors-explanation.5.gz
eza /usr/share/man/man5/eza_colors.5.gz
eza /usr/share/zsh/
eza /usr/share/zsh/site-functions/
eza /usr/share/zsh/site-functions/_eza

[cafkafk]

Arch linux has provided exa in eza.

On the other hand, nixpkgs decided not to do that, and home-manager still hasn't decided between replacing or deprecating.

Ultimately, that's the choice of the distributors of eza. I am fine with whatever outcome is chosen downstream, but one of our primary goals should be avoiding unnecessary breakage.

[cafkafk]

I wanted to repost this from nixpkgs here.

---

I was made aware that Archlinux Extra does have symlink from exa to eza. There is also a noticeable amount of users that have asked for this.

That said, I personally prefer users making this a conscious choice.

But we might provide some feature flag that creates a symlink or something like it, and I'll make sure to add it to eza in nixpkgs on the following release as a lib.optional, in the same way we currently do gitSupport. That should make most people happy. (@peterhoeg)?

[Freed-Wu]

we might provide some feature flag that creates a symlink or something like it,

Currently, archlinux's eza's exa doesn't have shell completions. only eza's eza have. Maybe the provided feature will fix this problem?

[cafkafk]

I mean they could just s/eza/exa/g in the completions downstream tbh, this isn't really something that eza should do.

[WhatsThatItsPat]

I'm guessing this ship has sailed, but you should have called it "ecksa" (ecks + a) and maintained the same pronunciation. You could have used that for the official name, but then you could have tried to keep using "exa" for the command.

Anyway, thanks for keeping this great project going.

[joecastro]

+1 on the "I'm guessing this ship has sailed" and +100 on "Thanks for keeping this project going". I just stumbled across this as I've been using exa for quite a while.

One practical observation (also clearly not a universal one because of different keyboard layouts): eza is more difficult to type on an ANSI QWERTY keyboard. With ls you just use your ring fingers on the home row, which is super ideal and minimal. With exa the command at least uses three separate fingers, albeit on different rows so there's slightly more hand contortion, but it's still relatively instantaneous once the muscle memory is down.

eza simply requires more travel on the keyboard. For touch typing with a QWERTY layout the "z -> a" travel is just kinda awkward for a command that is used so commonly.

I know people can alias commands. I had previously done alias ls='eza -l'. But the aliases aren't standard across all distributions and having a cogent default can be a boon. At the moment I'm thinking I'm going to alias to kd since it winds up physically close to ls and I can mentally map "kd - know directory contents" (a la man ls)

I want to reiterate, thanks again for bringing this back to active support. I just wanted to drop a note in case this decision is ever revisited.