With the rules being set out for "put this but not that" into `.zshenv` and other files, would it be possible to write a linter or checking tool to help enforce good style on those files?
Just to let you know that I'm forwarding this around to a bunch of folks I know and/or work with, to help them get to grips with `zsh` due to Catalina upgrades.
Thank you for writing this, it's seriously good stuff and I've learned things despite using zsh for several years now.
I really don't care what shell I use as long as it's POSIX compatible, so I just go with the default, which means either bash, ksh, ksh93, FreeBSD sh (which I think is an older version of dash?), or zsh. (I use a mixture of Linux/FreeBSD/OpenBSD/Solaris/macOS, and occasionally other systems as well).
I have some semi-elaborate dotfiles that work with every shell, but each shell uses different startup files, some shells don't have a distinction between login and interactive, etc, so I made a single idempotent config file that sets everything, and every shell-specific config file just sources that (which means some shells will source my config file twice, but that's ok).
Dotfiles that I didn't create myself are bad enough, but now they become even worse because they are harder to get to.
XDG_CONFIG_HOME is just putting the trash under the rug and claiming you cleaned the house.
Of course, because now dotfiles are harder to get to, it encourages software to create even more spam.
One possible useful function of the XDG variables would be to set XDG_DOWNLOAD_DIR to $HOME. That never seems to work for me.
It's bizarre to me that other people like these hierarchies. I prefer everything to be as flat as possible. I used to keep all my source code in $HOME/src (everything, C code, Go code, GCC, the Linux kernel, etc) and I wish I could have kept it in $HOME. I couldn't do that because of GOPATH, but now with Go modules I finally can!
I like the fact that I can put ~/.config under VCS more easily than I can put ~/ under a VCS.
OTOH, I've recently (months) started to use yadm[1] and seeing that it maybe doesn't matter and all I needed was a tool to make managing my home & configurations in a simpler way.
Tangential, but I recently got a massive speed up in my zplug-based load time with a simple `touch $ZPLUG_LOADFILE`. More discussion here: https://github.com/zplug/zplug/issues/368
If you want even better startup speed, try `zplugin`[0]. It can load plugins
asynchrously after your shell starts up, or after you type the first few
characters of a command.
If something like `export PATH="aa:$PATH"` is written in `.zshenv`, as the file is sourced even for nested zsh sessions, a new `aa` will be prepended for each zsh level. Consider protecting that kind of expansion (if you use it) with `if [[ $SHLVL == 1 ]]; then ...; fi`.
Yes in a way; we work with both bash and zsh, and have a similar repos for config files.
We are experiencing many developers switching from bash to zsh because of the recent macOS Catalina OS upgrade, and we want to show how bash and zsh can be configured similarly.
We want to easily clone a group of shell helpers (aliases, functions, etc.) that can use our preferred conventions and abstractions, and can run on a wide range of systems.
For zsh, you'd be better off handling functions via the function autoloading mechanism rather than defining them all from .zshenv. It is common to create a directory named ~/.zfunc (or similar), add that to $fpath and autoload the contents. This is rather more efficient than predefining them all as you would in bash.
That said, looking at your functions, a function which just runs rsync with a bunch of options and "$@" should either be done via an alias (which preserves zsh rsync completion) or as an rsync alias in ~/.popt.
I'd do that as a zsh plugin. If you do one that's oh-my-zsh compatible, it'll work with most of the frameworks, and you can install it by hand if you're running bare ZSH.
Then they just need to occasionally `git pull` to get updates to your company script collection.
If you have them use a ZSH framework, (I recommend https://github.com/tarjoilija/zgen for load speed), the good ones can handle the periodic pulls for you automagically.
This repo README may be helpful to people who are new to Z shell, and want to know the load order, and what's good to put in each file.
I'm the repo maintainer and I welcome constructive feedback.
OMG Thank you!
I’ve only read the first quarter, but excellent job... the extreme clarity is hugely awesome!
“What goes in it” and “what does not go in it” thank you thank you thank you thank you!
Oh, a thought occurs to me:
With the rules being set out for "put this but not that" into `.zshenv` and other files, would it be possible to write a linter or checking tool to help enforce good style on those files?
Just to let you know that I'm forwarding this around to a bunch of folks I know and/or work with, to help them get to grips with `zsh` due to Catalina upgrades.
Thank you for writing this, it's seriously good stuff and I've learned things despite using zsh for several years now.
Your website, http://sixarm.com doesn't load. It simply times out.
I really don't care what shell I use as long as it's POSIX compatible, so I just go with the default, which means either bash, ksh, ksh93, FreeBSD sh (which I think is an older version of dash?), or zsh. (I use a mixture of Linux/FreeBSD/OpenBSD/Solaris/macOS, and occasionally other systems as well).
I have some semi-elaborate dotfiles that work with every shell, but each shell uses different startup files, some shells don't have a distinction between login and interactive, etc, so I made a single idempotent config file that sets everything, and every shell-specific config file just sources that (which means some shells will source my config file twice, but that's ok).
Worked well for me for the past ~15 years.
If anyone cares: https://github.com/4ad/dotfiles
I wish more software were to use ${XDG_CONFIG_HOME:-$HOME} or similar instead of just putting stuff in $HOME
I hate that.
Dotfiles that I didn't create myself are bad enough, but now they become even worse because they are harder to get to.
XDG_CONFIG_HOME is just putting the trash under the rug and claiming you cleaned the house.
Of course, because now dotfiles are harder to get to, it encourages software to create even more spam.
One possible useful function of the XDG variables would be to set XDG_DOWNLOAD_DIR to $HOME. That never seems to work for me.
It's bizarre to me that other people like these hierarchies. I prefer everything to be as flat as possible. I used to keep all my source code in $HOME/src (everything, C code, Go code, GCC, the Linux kernel, etc) and I wish I could have kept it in $HOME. I couldn't do that because of GOPATH, but now with Go modules I finally can!
I like the fact that I can put ~/.config under VCS more easily than I can put ~/ under a VCS.
OTOH, I've recently (months) started to use yadm[1] and seeing that it maybe doesn't matter and all I needed was a tool to make managing my home & configurations in a simpler way.
[1]: https://yadm.io/
I don't mind things being created in the $HOME directory but the inconsistent casing as different applications create folders can be annoying
Fully agree. In fact, we use these XDG helper functions.
Tangential, but I recently got a massive speed up in my zplug-based load time with a simple `touch $ZPLUG_LOADFILE`. More discussion here: https://github.com/zplug/zplug/issues/368
If you want even better startup speed, try `zplugin`[0]. It can load plugins asynchrously after your shell starts up, or after you type the first few characters of a command.
[0]: https://github.com/zdharma/zplugin
If something like `export PATH="aa:$PATH"` is written in `.zshenv`, as the file is sourced even for nested zsh sessions, a new `aa` will be prepended for each zsh level. Consider protecting that kind of expansion (if you use it) with `if [[ $SHLVL == 1 ]]; then ...; fi`.
‘typeset -U path’ would be a more simple alternative.
Yeah, I like this in zsh:
Apart from the clever .d directory support, doesn't this mirror bash (in theory)?
Yes in a way; we work with both bash and zsh, and have a similar repos for config files.
We are experiencing many developers switching from bash to zsh because of the recent macOS Catalina OS upgrade, and we want to show how bash and zsh can be configured similarly.
We want to easily clone a group of shell helpers (aliases, functions, etc.) that can use our preferred conventions and abstractions, and can run on a wide range of systems.
For zsh, you'd be better off handling functions via the function autoloading mechanism rather than defining them all from .zshenv. It is common to create a directory named ~/.zfunc (or similar), add that to $fpath and autoload the contents. This is rather more efficient than predefining them all as you would in bash.
That said, looking at your functions, a function which just runs rsync with a bunch of options and "$@" should either be done via an alias (which preserves zsh rsync completion) or as an rsync alias in ~/.popt.
Excellent, thank you for the constructive advice! I'll start in on it.
That's good advice, thank you.
I'd do that as a zsh plugin. If you do one that's oh-my-zsh compatible, it'll work with most of the frameworks, and you can install it by hand if you're running bare ZSH.
Then they just need to occasionally `git pull` to get updates to your company script collection.
I wrote a brief set of guidelines at https://github.com/unixorn/awesome-zsh-plugins/blob/master/W...
If you have them use a ZSH framework, (I recommend https://github.com/tarjoilija/zgen for load speed), the good ones can handle the periodic pulls for you automagically.