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:
The problem is that we don't just live on our own machines. We hop around to different boxes and just being able to type what you are used to matters. My dotfiles and other tools don't go or even work everywhere.
We shouldn't change the oldest parts of our OSes without a really good reason.
For one I think the example doesn't really fit, as Linux binaries are much closer to modules than they are to plain functions, as each of those binaries has numerous command line flags to change it's behavior quite radically. Functions as you encounter in a programming language are much simpler and more focused.
The other issue is that the approach is extremely inflexible, if you want to replace /usr/bin/program with a new version, everybody on the system is forced to use the new version, even if the new version might break stuff. Traditional `/usr/bin` doesn't provide a solution for this. You can of course work around that by using `/opt` or installing things in your home directory, but at that point you are just using the file system as namespace.
I liked the last in point in particular. It's one of the reasons I don't keep dotfiles around and even my vim configuration is minimal.
I'd rather get used to defaults in case I need to use another computer in a pinch than getting used to a system and having to google how to do every little thing when in another system. I picked up that habit, when I had to work on remote servers nearly every day.
That's probably a bit zealous of me, but I've gotten used to it.
I think worse is better here. This just sounds like another layer of abstraction and complexity i want to avoid dealing with as it will consume head space and detract from actually solving the problem i am there to solve.
I tend to make do with defaults as well i.e basic vi and ksh as i move between BSD and Linux regularly (and rarely Solaris 2.5 still!). No surprises and very few dotfiles.
The reasons for the complexity are lame, but sometimes there are nice consequences. For instance, on FreeBSD you can pretty much just nuke /usr/local/ and be left with a functional base-system (broken configs notwithstanding).
as if there even was one command-line or config standard. especially across different operating systems.
it absolutely does not belong in stdlibs, where it can never be changed. that's how you end up with too many terrible CLI tools using Go's `flags` package.
It sounds almost like the OP is bemoaning the stability of Unix-like systems. I like that ls, cd, mkdir, emacs and cp all work more or less the same way. And as much as I sometimes curse at autotools, I appreciate how nice it is I can generally just type `./configure` and something reasonable happens.
That's what I'm talking about. I'm super comfortable reading the man pages for things, but if a tool wants to take over all the boilerplate and do things for me, awesome! Sure, I can add a function by editing rc files. That doesn't scare me one bit. But... why? There's a lot to be said for convention over configuration.
For context, for a while I was the FreeBSD port maintainer for shells/bash-completion. I'm (too) familiar with the plumbing of various shells. I can do all the manual work myself, but there are lots of things I'd rather be doing instead.
I agree completely, but like to think of it a little differently.
While it's easy enough to put your dotfiles on github, and pull them down onto every machine you touch, or possibly even automate that, it doesn't solve the fundamental problem that software that requires extensive customization is not good software.
If the right trade-offs haven't already been made in the default configuration, then it's an immature application waiting for a rewrite.
I agree with the sentiment, and it's exactly why I switched from a ready made emacs setup to a custom-rolled config.
Most of the stuff bundled in it isn't really necessary, and just makes it harder to understand the clean environment if you're new to it.
Even though it's more work, it's nice to know exactly how you're configuring your own environment, and you get to learn more about it as you do configure it.
To that extent I'm not even a fan of emacs' new package manager.
I just use whatever is the default in the terminal or IDE. I used to care (it was either Consolas or Source Code Pro for me) but now I find it easier to just not care about it.
I can think of two reasons: It's arguably a hack and it's not needed.
While this is awesome, it can easily break (zsh already seems to do so) and, as the author states, it is not meant for GUI apps or programs relying deeply on OS APIs, which includes a lot of apps.
Additionaly, it does not solve an important problem. Doing a build for each supported OS is not that hard and easily automated. The actual problem is to be able to reuse code and this is solved for the most part.
If there is a small number of rarely changing binaries (like icons, tool configs, etc.) then it may not be worth it to move them. Also if space is much cheaper than tool complexity and build time.
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...
reply