gmane.comp.shells.zsh.user

Richard Hartmann | 24 Jul 13:48

A scheme to manage several ZSH config file collections?

Hi all,

some of you might be aware of grml, a live boot CD which uses ZSH as its
default shell. I suggested integrating several different zshrc files
along with whatever other files they need and offer the user a selection
of said configuration files.

Now, we are wondering if there is a clean and maintainable way to do
this. I have had a few ideas in this direction and would like to discuss
those here. New suggestions are more than welcome as well, of course.
Ideally, the same versions should be usable on the machines of whoever
maintains those files, so that changes can be merged back and forth
easily, which will allow more people to participate.

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

2) Use symlinks
    Pro: Fast to set up
    Con: All shells are forced to use the same RC files
         Shells can not be allowed to start prior to rc file selection
         Ugly & hackish

3) Use $ZSHRC_PREFIX or some similar variable
    Pro: Drop-in solution once you change your RC files for the first
           time

(Continue reading)

Peter Stephenson | 24 Jul 14:05

Re: A scheme to manage several ZSH config file collections?

"Richard Hartmann" wrote:
> Hi all,
> 
> some of you might be aware of grml, a live boot CD which uses ZSH as its
> default shell. I suggested integrating several different zshrc files
> along with whatever other files they need and offer the user a selection
> of said configuration files.
> 
> Now, we are wondering if there is a clean and maintainable way to do
> this.

I don't know enough about this set-up to be able to answer this properly.
I presume the system is strictly booting and configuring from CD only,
so every time you boot you get to pick choices from scratch (i.e. every
time it looks like the user has been freshly created), however I don't
know how things are stored once the system is running.

You later refer to "for the first time"... I presume you mean that
although the stuff needs doing each time you boot from the CD, later
instances of the shell will pick up the same settings?  Do you have a
writeable home area for the user in which .zshrc files can be copied for
this?  In that case, the zsh/newuser module added to the main line (and
in recent 4.3 releases) should be something like what you want, since it
runs if there are no existing user startup files.  You may well want to
adapt the zsh-newuser-install function to your own ends: you can simply
write a drop-in replacement for this without altering the core of the
system---it's been designed with this in mind.  You can simply get
zsh-newuser-install to write a .zshrc that sources the appropriate
selected set of files, or copy in as much or as little code and
comments as you want.  Then the user can just edit the .zshrc.

(Continue reading)

Richard Hartmann | 24 Jul 15:56

Re: A scheme to manage several ZSH config file collections?

On Thu, Jul 24, 2008 at 14:05, Peter Stephenson <pws <at> csr.com> wrote:

> I don't know enough about this set-up to be able to answer this properly.
> I presume the system is strictly booting and configuring from CD only,
> so every time you boot you get to pick choices from scratch (i.e. every
> time it looks like the user has been freshly created), however I don't
> know how things are stored once the system is running.

In most cases, it is, in fact, a 'blank' CD without any volatile data. There
are ways to install grml as well as ways to keep a persistant overlay
and/or home directory on usb sticks, hdds and the likes, as well.

> You later refer to "for the first time"... I presume you mean that
> although the stuff needs doing each time you boot from the CD, later
> instances of the shell will pick up the same settings?

Yes. The session on tty1 already does display a small 'how to get
started, would you like to set up some stuff' menu which could be
expanded accordingly.
The shells on the other ttys should wait for this decission to be
made. Alternatively, they could time out and load a default or wait
until said decission is made or a key is pressed in which case they
would load the default config.

>  Do you have a
> writeable home area for the user in which .zshrc files can be copied for
> this?  In that case, the zsh/newuser module added to the main line (and
> in recent 4.3 releases) should be something like what you want, since it
> runs if there are no existing user startup files.  You may well want to
> adapt the zsh-newuser-install function to your own ends: you can simply

(Continue reading)

Peter Stephenson | 24 Jul 16:06

Re: A scheme to manage several ZSH config file collections?

"Richard Hartmann" wrote:
> Other than sending a HUP/USR1/USR2 and trapping it in all other
> zsh-newuser-install, are there any other mechnanisms that would
> enable the other instances to know that a configuration decission
> has been made?

So you're worrying about the case where multiple shells have started,
discovered that there's no .zshrc, and are all waiting for user input?

No, I don't think there's an easy way round; you'd have to trap that in
the function.  They could sleep waiting for input and checking for
.zshrc, I suppose, but that's a bit messy.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Richard Hartmann | 24 Jul 16:15

Re: A scheme to manage several ZSH config file collections?

On Thu, Jul 24, 2008 at 16:06, Peter Stephenson <pws <at> csr.com> wrote:

> So you're worrying about the case where multiple shells have started,
> discovered that there's no .zshrc, and are all waiting for user input?

Yes.

> No, I don't think there's an easy way round; you'd have to trap that in
> the function.  They could sleep waiting for input and checking for
> .zshrc, I suppose, but that's a bit messy.

Yah, those are the two options I came up with. Are any of the usual kill
signals in use, by default? Once zsh-newuser-install ends (itself), the
trap can simply be released and normal usage can continue.

Richard

Peter Stephenson | 24 Jul 16:18

Re: A scheme to manage several ZSH config file collections?

"Richard Hartmann" wrote:
> > No, I don't think there's an easy way round; you'd have to trap that in
> > the function.  They could sleep waiting for input and checking for
> > .zshrc, I suppose, but that's a bit messy.
> 
> Yah, those are the two options I came up with. Are any of the usual kill
> signals in use, by default? Once zsh-newuser-install ends (itself), the
> trap can simply be released and normal usage can continue.

Signals aren't overloaded by the shell beyond their standard meanings,
so you shouldn't have any trouble.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Richard Hartmann | 24 Jul 16:28

Re: A scheme to manage several ZSH config file collections?

On Thu, Jul 24, 2008 at 16:18, Peter Stephenson <pws <at> csr.com> wrote:

> Signals aren't overloaded by the shell beyond their standard meanings,
> so you shouldn't have any trouble.

Perfect.

I will mail the list with our finished solution. Perhaps others can use
something like this, as well. Or it might even find its way into trunk.
Who knows :)

Richard

Richard Hartmann | 24 Jul 16:40

Re: A scheme to manage several ZSH config file collections?

On Thu, Jul 24, 2008 at 16:28, Richard Hartmann
<richih.mailinglist <at> gmail.com> wrote:

> Or it might even find its way into trunk.

Actually, if the above was yet another option in the starting
dialogue.. Said option could simply be omitted if there is no
array with possible config names in it (and, optionally, a
base path for those configs).

Would that be of any interest to ZSH at large?

Richard

Peter Stephenson | 24 Jul 16:58

Re: A scheme to manage several ZSH config file collections?

"Richard Hartmann" wrote:
> On Thu, Jul 24, 2008 at 16:28, Richard Hartmann
> <richih.mailinglist <at> gmail.com> wrote:
> 
> 
> > Or it might even find its way into trunk.
> 
> Actually, if the above was yet another option in the starting
> dialogue.. Said option could simply be omitted if there is no
> array with possible config names in it (and, optionally, a
> base path for those configs).
> 
> Would that be of any interest to ZSH at large?

Possibly, but I'm not quite sure what you're proposing.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Richard Hartmann | 24 Jul 17:10

Re: A scheme to manage several ZSH config file collections?

On Thu, Jul 24, 2008 at 16:58, Peter Stephenson <pws <at> csr.com> wrote:

> Possibly, but I'm not quite sure what you're proposing.

Basically, it is this:

Suppose that the normal zsh-newuser-install has a
mechanism which will detect rc files provided by ZSH, the
distribution or the local admin and offer the user to use
any of them. A short description should probably be
provided for each rc file collection. Also, an easy way to
choose another of the available options at a later point,
i.e. when the user wants to try something else, should
probably be provided.

Richard

Peter Stephenson | 24 Jul 17:15

Re: A scheme to manage several ZSH config file collections?

"Richard Hartmann" wrote:
> On Thu, Jul 24, 2008 at 16:58, Peter Stephenson <pws <at> csr.com> wrote:
> 
> > Possibly, but I'm not quite sure what you're proposing.
> 
> Basically, it is this:
> 
> Suppose that the normal zsh-newuser-install has a
> mechanism which will detect rc files provided by ZSH, the
> distribution or the local admin and offer the user to use
> any of them. A short description should probably be
> provided for each rc file collection. Also, an easy way to
> choose another of the available options at a later point,
> i.e. when the user wants to try something else, should
> probably be provided.

Oh, OK.

I suppose it could look for configurations somewhere under the
share/zsh/≤version> directory and list what it finds and print a
comment.

--

-- 
Peter Stephenson <pws <at> csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Frank Terbeck | 24 Jul 14:18

Re: A scheme to manage several ZSH config file collections?

[dropping zsh-users from Cc: as they would only be marginally involved
 here]

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

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.

(Continue reading)

Frank Terbeck | 24 Jul 14:58

Re: A scheme to manage several ZSH config file collections?

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.

(Continue reading)

Richard Hartmann | 24 Jul 16:31

Re: A scheme to manage several ZSH config file collections?

On Thu, Jul 24, 2008 at 14:58, Frank Terbeck <ft <at> grml.org> wrote:

>>  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:

If there _is_ no normal zshrc, zsh-newuser-install will run. As we can
easily replace this function, ZSH does the handling of this for free.
The default zsh could be loaded the second a user presses enter on
the little welcome screen menu grml displays on tty1 and everything
set up to use this config, as well. Said menu would run from
zsh-newuser-install then, btw.

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

As I autoload every one of my functions in my zshrc via globbing, I
would want to keep softlinks for the functions moved into main,
but yes, that is a good idea.

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

(Continue reading)

Frank Terbeck | 24 Jul 21:07

Re: A scheme to manage several ZSH config file collections?

Richard Hartmann <richih.mailinglist <at> gmail.com>:
> On Thu, Jul 24, 2008 at 14:58, Frank Terbeck <ft <at> grml.org> wrote:
> >>  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:
> 
> If there _is_ no normal zshrc, zsh-newuser-install will run. As we can
> easily replace this function, ZSH does the handling of this for free.

As I said, I would not want to touch /etc/zsh/zshrc. It will always be
there. Hence, the catch is needed.

I also do not want to touch ~/.zshrc. It should always be there. If we
can set ZDOTDIR before zsh is run, we do have means to support the
*full* range of zsh config files. No need to touch ~/.zshrc at all.

I really would prefer to keep grml's zsh config like it is now, and if
you want to switch, you use a function, say 'zmode <whateverrc>' to
spawn a differently set up shell.

You can even write the current mode into a file, so that subsequently
opened shells automatically use that setup.

No need to fiddle with newuser-install, at all.

[...]
> >>  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.

(Continue reading)

Frank Terbeck | 24 Jul 21:12

Re: A scheme to manage several ZSH config file collections?

Frank Terbeck <ft <at> grml.org>:
> Richard Hartmann <richih.mailinglist <at> gmail.com>:
> > On Thu, Jul 24, 2008 at 14:58, Frank Terbeck <ft <at> grml.org> wrote:
[...]
> > >>     Do NOT source /etc/zsh/zshrc in that case.
> > 
> > This should exist and overwrite the normal zsh-newuser-install.
> 
> It shou

*sigh* I wish, I had someone who'd proveread my mails, before I send
them out...

What I wanted to say here, is that I don't understand what is meant by
that sentence. I've read it a few times, I just don't undestand, what
it is supposed to say.

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

Frank Terbeck | 24 Jul 22:39

Re: A scheme to manage several ZSH config file collections?

Frank Terbeck <ft <at> grml.org>:
> Richard Hartmann <richih.mailinglist <at> gmail.com>:
> > On Thu, Jul 24, 2008 at 14:58, Frank Terbeck <ft <at> grml.org> wrote:
> > >>  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:
> > 
> > If there _is_ no normal zshrc, zsh-newuser-install will run. As we can
> > easily replace this function, ZSH does the handling of this for free.
> 
> As I said, I would not want to touch /etc/zsh/zshrc. It will always be
> there. Hence, the catch is needed.
> 
> I also do not want to touch ~/.zshrc. It should always be there. If we
> can set ZDOTDIR before zsh is run, we do have means to support the
> *full* range of zsh config files. No need to touch ~/.zshrc at all.
> 
> I really would prefer to keep grml's zsh config like it is now, and if
> you want to switch, you use a function, say 'zmode <whateverrc>' to
> spawn a differently set up shell.
> 
> You can even write the current mode into a file, so that subsequently
> opened shells automatically use that setup.
> 
> No need to fiddle with newuser-install, at all.
[...]
> > >>     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.)

(Continue reading)

Return

Return to gmane.comp.shells.zsh.user.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane