[Grml] A scheme to manage several ZSH config file collections?

[Frank Terbeck]

Frank Terbeck <ft at grml.org>:
> Richard Hartmann <richih.mailinglist at gmail.com>:
> [..multiple zshrcs in grml..]
> > 1) Make ZSH load the RC files from different paths (/etc/zsh/config1 ..)
> >     Pro: Almost drop-in, minimal work necessary
> >          Cleanly seperated
> >          Different ttys might run with different RC files
> >     Con: Needs modification to fpath etc
> >          Shells can not be allowed to start prior to rc file selection
> [...]
> > 3) Use $ZSHRC_PREFIX or some similar variable
> >     Pro: Drop-in solution once you change your RC files for the first
> >            time
> >          Cleanly seperated
> >          Different ttys might run with different RC files
> >     Con: Shells can not be allowed to start prior to rc file selection
> >          Needs a way for ZSH to be started with a variable set before it
> >            is invoked

Some more thoughts:

> I've snipped out solution no2, as I don't think that it is the best
> way to go.
> 
> Actually, I'm tending towards a mixture of the two remaining
> solutions:
> 
>  1. Don't touch the current zshrc at all. It works fine and should be
>     left intact unmodified.

We'll need to stop the normal zshrc from sourcing, so something like:

[[ -n $ZSHRC_ALT ]] && [[ -e /etc/zsh/rcs/zshrc.$ZSHRC_ALT ]] && return

...would be needed.

>  2. Give all added rcs their own file + function dir (I don't think an
>     additional completion dir is needed):
> 
>     /etc/zsh/rcs/zshrc.richih
>     /etc/zsh/rcs/richih.d/
> 
>  3. Put *every* function file, that does not collide with the ones
>     that are already in grml's configuration into
>     /etc/zsh/functions.d; There's no reason from keeping non-colliding
>     function to not be in the standard config.

Unless, the function does only have value in connection with the
configuration in question.

>  4. add /etc/zsh/rcs/richih.d/ at the *beginning* be $fpath so that
>     colliding functions are not taken from the default dir, but from
>     the dir that is part of the config, that is in action.
> 
>  5. If $ZSHRC_ALT (I think _ALT is a better name when choosing an
>     alternate configuration) is set to a name (say richih), use
>     /etc/zsh/rcs/zshrc.$ZSHRC_ALT if it is available.
> 
>     Do NOT source /etc/zsh/zshrc in that case.
>     Do NOT source ~/.zshrc in that case (set $ZDOTDIR to
>     ~/.zshrc.$ZSHRC_ALT - that would make ~/.zshrc.$ZSHRC_ALT/.zshrc
>     to be sourced; standard zsh mechanism.)

That gives full support for user configuration, as pws mentioned on
zsh-users.

We should touch a .zshrc in there if a given configuration does not
provide one in order to avoid the newuser-module-dialog.

>  5. Do the handling of $ZSHRC_ALT, $ZDOTDIR and $fpath in the global
>     zshenv (/etc/zsh/zshenv) in a
> 
>         if [[ -o interactive ]] ; then
>         fi
> 
>     Block;

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925