While it's not the intention to replace the binary itself, I'm just not a fan of the idea of substituting system built-ins in everyday behavior. Stuff like cd, ls, etc. I like to keep it to the basics.
Even just with PATHs or aliases, or a new binary entirely.
And I'm a person who is no stranger to dot-configs. I've never taken it as far as Z(1), https://github.com/rupa/z.
A system builtin is stuff you'd see stowed away in /bin. They are essential low level binaries you have to trust. If somehow a malicious ls got out there, nothing's stopping people from writing memory-safe malware that uploads your $HOME configs to some server in a far away land.
The more I say this, I guess defaulting to a substitute for a builtin command doesn't matter. The average developer relies on so much third party stuff in their shell, vim, package manifests, and so on that all these years could have done bad stuff, nothing has happened.
Maybe it's my defense mechanism firing that my own dot-config has grown so big I don't remember what the hell's in it anymore.
In fact, it's a common thing for terminal applications to accept environmental variables to use third party applications. For instance, $EDITOR, and less often (but no less useful): $PAGER. You can give it a shot with most(1) [1], I mention it in my book, The Tao of tmux [2] (available free to read online).
So also, regarding $EDITOR, if you prefer that being in GNU nano, Pico, Vim, or emacs, set it in your .bashrc/.zshrc:
export EDITOR=vim
Also, for git's editor, I don't remember if it falls back to $EDITOR, but you can do:
export GIT_EDITOR=vim
Another tool at your disposal for ls(1), which even FreeBSD supports, it $LS_COLORS:
It's not overriding anything, so you're ranting against a faulty premise. The command is called "exa", not "ls", and it isn't even a drop-in replacement -- it doesn't have the same flags. You can't alias "ls" to it.
The focus over the qualifier of whether it's "drop-in" misses the point. How else are people going to interpret and use "a modern replacement for ls", in practice?
Not to replace the file /bin/ls itself. Users will symlink/PATH/alias exa in as "ls" in front of /bin/ls in their shell for convenience.
So? Nobody is going to use this to replace "ls" in scripts. Are you really arguing against the creation of competing tools? "ack" shouldn't exist because "grep" already exists? "htop" shouldn't exist because there's "top"?
Put it this way: Think of it like a Socratic dialog. Just because a replacement for ls(1) may not be beneficial due to configuration and customization already being commonplace, isn't the same as saying the mere notion of a competing unix CLI tool is bad.
top(1) doesn't allow color configuration. I use htop(1), and like it.
ls(1) already has color customization via LS_COLORS and long-list format via -l in ls. And about 10+ other output options. It's quite flexible.
git status can be shown via `git status`, and via the PS1 in oh-my-zsh/pure.
> Nobody is going to use this to replace "ls" in scripts.
I'm concerned they will, and not recognize it. To beginner and novice shell users, it's easier to cargo cult stuff in and not know what's happening. And things will break in ways that's a nightmare for them to troubleshoot.
My gut instinct is being verified by comments in this thread mentioning alias'ing in exa as ls.
If anyone is silly enough to alias to exa, then their scripts will fail. A replacement doesn't have to be a drop in. Server admins who alias it will pay the price, so they won't do it.
Shell scripts break. If it's not a parity with ls(1), the output and arguments won't be compatible.
I forgot to add: Having colors / fancy output when you just want to pipe information around the shell is of no value.
IMO it goes against the spirit of what commands like ls are meant to do, and the behavior exa provides is better placed, and already done well, via shell configuration (e.g. oh-my-zsh, presto, pure)
Even just with PATHs or aliases, or a new binary entirely.
And I'm a person who is no stranger to dot-configs. I've never taken it as far as Z(1), https://github.com/rupa/z.
A system builtin is stuff you'd see stowed away in /bin. They are essential low level binaries you have to trust. If somehow a malicious ls got out there, nothing's stopping people from writing memory-safe malware that uploads your $HOME configs to some server in a far away land.
The more I say this, I guess defaulting to a substitute for a builtin command doesn't matter. The average developer relies on so much third party stuff in their shell, vim, package manifests, and so on that all these years could have done bad stuff, nothing has happened.
Maybe it's my defense mechanism firing that my own dot-config has grown so big I don't remember what the hell's in it anymore.
In fact, it's a common thing for terminal applications to accept environmental variables to use third party applications. For instance, $EDITOR, and less often (but no less useful): $PAGER. You can give it a shot with most(1) [1], I mention it in my book, The Tao of tmux [2] (available free to read online).
So also, regarding $EDITOR, if you prefer that being in GNU nano, Pico, Vim, or emacs, set it in your .bashrc/.zshrc:
export EDITOR=vim
Also, for git's editor, I don't remember if it falls back to $EDITOR, but you can do:
export GIT_EDITOR=vim
Another tool at your disposal for ls(1), which even FreeBSD supports, it $LS_COLORS:
http://man7.org/linux/man-pages/man5/dir_colors.5.html
edit: actually, BSD's ls(1) seems to be $LSCOLORS (https://www.freebsd.org/cgi/man.cgi?query=ls&sektion=1):
[1] http://www.jedsoft.org/most/
[2] https://leanpub.com/the-tao-of-tmux/read#leanpub-auto-read-t...