
Show HN: Z shell configuration, zsh startup files, when they load, what they do - jph
https://github.com/SixArm/sixarm_zsh_config
======
jph
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.

~~~
an_d_rew
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!

------
4ad
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](https://github.com/4ad/dotfiles)

------
mfontani
I wish more software were to use ${XDG_CONFIG_HOME:-$HOME} or similar instead
of just putting stuff in $HOME

~~~
4ad
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!

~~~
mfontani
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/](https://yadm.io/)

------
tombh
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](https://github.com/zplug/zplug/issues/368)

~~~
Seirdy
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](https://github.com/zdharma/zplugin)

------
rucikir
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`.

~~~
soraminazuki
‘typeset -U path’ would be a more simple alternative.

~~~
bloopernova
Yeah, I like this in zsh:

    
    
        # Only allow unique entries in the PATH variable
        typeset -U path
    
        # Easier to read PATH variable modification:
        path+=(
          "${JAVA_HOME}/bin"
          "${GOPATH}/bin"
        )

------
toyg
Apart from the clever .d directory support, doesn't this mirror bash (in
theory)?

~~~
jph
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.

~~~
opk
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.

~~~
jph
Excellent, thank you for the constructive advice! I'll start in on it.

