Mandrake 8.0 - compinit in /etc/zshrc

Mandrake 8.0 - compinit in /etc/zshrc

[Andrej Borsenkow]

I wanted to use versioned .zcompdump (home dir is shared between systems 
with different zsh versions) in .zshrc: compinit -d 
~/.zcompdump.${ZSH_VERSION}. To my surpsise, plain .zcompdump was still 
created. It turned out a call in /etc/zshrc.

I am not exactly happy about it ... one reason is above; the other one, 
should distribution unconditionally force user to use new completion?

Here is relevant part from /etc/zshrc:

# Completion functions
_compdir=/usr/share/zsh/$ZSH_VERSION/functions/Completion
[[ -z $fpath[(r)$_compdir] ]] && fpath=($fpath $_compdir)
autoload -U compinit
compinit

-andrej

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Bart Schaefer]

On May 19, 10:19pm, Andrej Borsenkow wrote:
} Subject: Mandrake 8.0 - compinit in /etc/zshrc
}
} I am not exactly happy about it ... one reason is above; the other one, 
} should distribution unconditionally force user to use new completion?

This is a philosophical decision along the lines of "should the default
zsh setopts include always_last_prompt and auto_list?" though a bit more
extreme.  I personally would say it should not.
 
} Here is relevant part from /etc/zshrc:
} 
} # Completion functions
} _compdir=/usr/share/zsh/$ZSH_VERSION/functions/Completion
} [[ -z $fpath[(r)$_compdir] ]] && fpath=($fpath $_compdir)
} autoload -U compinit
} compinit

Drop just the actual execution of "compinit" and the rest would be OK.

Anyway, the obvious workaround is to add to your .zshenv:

  alias compinit="compinit -d ${ZDOTDIR:-$HOME}/.zcompdump.$ZSH_VERSION"

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Wayne Davison]

On Sat, 19 May 2001, Bart Schaefer wrote:
> This is a philosophical decision along the lines of "should the default
> zsh setopts include always_last_prompt and auto_list?" though a bit more
> extreme.  I personally would say it should not.

I think that making an interactive zsh behave very powerfully by default
is a good idea.  However, I take issue with the execution.  Here's how I
would implement this:

Add a .zshrc file to the /etc/skel dir that includes this compinit code.
Then, add post-install code to the zsh rpm that gives a copy of this rc
file to all existing users that don't already have the file (for a
certain restricted definition of "all existing users").  This, in my
mind, is the proper way to add all those default aliases and other
things that the user might want to change (for both zsh and other
shells, such as bash).

..wayne..

RE: Mandrake 8.0 - compinit in /etc/zshrc

[Andrej Borsenkow]

>
> On Sat, 19 May 2001, Bart Schaefer wrote:
> > This is a philosophical decision along the lines of "should the default
> > zsh setopts include always_last_prompt and auto_list?" though a bit more
> > extreme.  I personally would say it should not.
>
> I think that making an interactive zsh behave very powerfully by default
> is a good idea.  However, I take issue with the execution.  Here's how I
> would implement this:
>
> Add a .zshrc file to the /etc/skel dir that includes this compinit code.

I like /etc/skel idea.

> Then, add post-install code to the zsh rpm that gives a copy of this rc
> file to all existing users that don't already have the file (for a
> certain restricted definition of "all existing users").

That is probably an overkill. Is there any other packages that does it?

-andrej

RE: Mandrake 8.0 - compinit in /etc/zshrc

[Wayne Davison]

On Sun, 20 May 2001, Andrej Borsenkow wrote:
> I previously wrote:
> > Then, add post-install code to the zsh rpm that gives a copy of this rc
> > file to all existing users that don't already have the file (for a
> > certain restricted definition of "all existing users").
>
> That is probably an overkill. Is there any other packages that does it?

No, it's not overkill, it's the vital part of the puzzle that makes
using /etc/skel work.  In the past when I (and others) have suggested
using /etc/skel, the packagers have said "what about existing users?"
and then they put the commands into a global init file so that it
affects everyone, old and new users alike.  Having all packages that
install /etc/skel files give the files to existing users (safely)
would take away this objection.

..wayne..

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Chmouel Boudjnah]

Wayne Davison <wayned@users.sourceforge.net> writes:

> No, it's not overkill, it's the vital part of the puzzle that makes
> using /etc/skel work.  In the past when I (and others) have suggested
> using /etc/skel, the packagers have said "what about existing users?"
> and then they put the commands into a global init file so that it
> affects everyone, old and new users alike.  Having all packages that
> install /etc/skel files give the files to existing users (safely)
> would take away this objection.

and how do you do when you have to modify the skel file on upgrade ?

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Clint Adams]

> and how do you do when you have to modify the skel file on upgrade ?

Why not have some sort of /usr/bin/clobber-my-zsh-dotfiles utility
script that you can encourage the user to run either manually or
through some automated process?

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Chmouel Boudjnah]

Clint Adams <clint@zsh.org> writes:

> Why not have some sort of /usr/bin/clobber-my-zsh-dotfiles utility
> script that you can encourage the user to run either manually or
> through some automated process?

we got in trouble and interactive question is not a solution this is
again our rpm policy install.

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Clint Adams]

> we got in trouble and interactive question is not a solution this is
> again our rpm policy install.

You could conceivably check from the global startup scripts, or
from the initial /etc/skel/.z*, whether or not a dotfile upgrade
is in order.

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Oliver Kiddle]

Bart Schaefer wrote:

> One possibility might be not to put the code directly into the skel file.
> Put it in, say, /etc/zsh.d/compinit.

This is much more sensible. Trying to modify existing user's .zshrc
files would be fraught with problems and bound to irritate some users.

Clint Adams wrote:

> You could conceivably check from the global startup scripts, or
> from the initial /etc/skel/.z*, whether or not a dotfile upgrade
> is in order.

What you could do, from the global .zlogin, is have something like:
if [[ /etc/skel/.zshrc -nt ~/.zshrc ]]; then
  echo Warning: skeleton .zshrc has changed
  touch ~/.zshrc  # display above message only once
fi

That way, old users would be alerted to the change and could update
their own .zshrc if they wanted.

Maybe we should allow zsh to be given some shell code at compile time
which would then be run at startup along with all the dot files. There'd
need to be a way to disable it (similar to the norcs option) and we'd
need to work out when it would fit in with the order of everything else.
It'd be ideal for compinit and any future zsh features which might be
done in shell code.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Chmouel Boudjnah]

Clint Adams <clint@zsh.org> writes:

> You could conceivably check from the global startup scripts, or
> from the initial /etc/skel/.z*, whether or not a dotfile upgrade
> is in order.

well i think i prefer to do check in  /etc/zshrc, if ~/.zcompdump*
exist before generating any zcompdump..

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Andrej Borsenkow]

Chmouel Boudjnah wrote:

> Clint Adams <clint@zsh.org> writes:
> 
> 
>>You could conceivably check from the global startup scripts, or
>>from the initial /etc/skel/.z*, whether or not a dotfile upgrade
>>is in order.
>>
> 
> well i think i prefer to do check in  /etc/zshrc, if ~/.zcompdump*
> exist before generating any zcompdump..
> 


I did not intend *that*. User is free to choose any name, not 
neccessarily .zcompdmup. The question is more general - should such 
things as completion, alias and like be put in system-wide startup file 
(and thus uncondtitionally forced on all users) or into user-specific 
template that user can review and possibly change.

-andrej

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Chmouel Boudjnah]

Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> writes:

> I did not intend *that*. User is free to choose any name, not
> neccessarily .zcompdmup. The question is more general - should such
> things as completion, alias and like be put in system-wide startup
> file (and thus uncondtitionally forced on all users) or into
> user-specific template that user can review and possibly change.

i believe that should not be in system-wide, but the thing is that our
philosphy we aims to ship things with a fullly optimized for easiness
and usability, so where i'll put that ? and as i say /etc/skel/ is not
a solution for us..

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Bart Schaefer]

On May 21,  3:40pm, Chmouel Boudjnah wrote:
}
} and how do you do when you have to modify the skel file on upgrade ?

One possibility might be not to put the code directly into the skel file.
Put it in, say, /etc/zsh.d/compinit.  In /etc/zshrc, define a shell
function:

    function ZSH_features() {
      local feature
      for feature in /etc/zsh.d/*(N-.:x)
      do
	. $feature
      done
      unfunction ZSH_features
    }

Then the skel .zshrc file would contain a block such as:

    # BEGIN: Standard zsh feature setup
    # This command initializes assorted features that are useful to all
    # users.  See /etc/zshrc for the definition of this function.
    # If you remove this command you may miss new features that are
    # added when the zsh packages are upgraded.  Edit at your own risk.
    typeset +f ZSH_features >/dev/null && ZSH_features
    # END: Standard zsh feature setup

Note that Wayne's suggestion is that you add a .zshrc file to the home
directories only of users who don't have one.  For users who already do
have one, scan the .zshrc for the BEGIN: line or the ZSH_featues command,
and if it isn't there, do something non-interactive, such as sending them
e-mail, to tell them about the upgrade -- and do that only if their login
shell is set to zsh.

I understand Trond's argument about users with non-local or NFS-shared
directories.  It'd be easy enough to skip (or do only the "send e-mail"
step for) the former; for the latter, the `typeset +f' check should 
prevent problems if they happen to use zsh on another machine yet for
some reason didn't already have a .zshrc file.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Wayne Davison]

On 21 May 2001, Chmouel Boudjnah wrote:
> and how do you do when you have to modify the skel file on upgrade ?

Here's an alternate solution.  See if you like this.

For a package such as zsh, create a patch in the source rpm that adds
an extra rc-file check that works like this:  If the user's rc file is
missing, we read the default rc file from /usr/lib/zsh (or similar).
This gives all users the default "power options" up until they decide to
take their fate into their own hands and create their own rc file, at
which time they are responsible for updating it on upgrade.  The only
downside I see in this is that the user needs to be made aware that when
they create their own rc file, that they may wish to copy the default rc
file and modify that rather than starting from scratch.  Do you think
that is too big of a problem?  (I don't consider the fact that a user
that creates their own rc file may need to edit their rc file on upgrade
a problem since these users already have to deal with changing their rc
file on upgrade in the current scheme to handle interactions between the
new system rc and their old home rc file).

..wayne..

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Andrej Borsenkow]

Wayne Davison wrote:

> On 21 May 2001, Chmouel Boudjnah wrote:
> 
>>and how do you do when you have to modify the skel file on upgrade ?
>>
> 
> Here's an alternate solution.  See if you like this.
> 
> For a package such as zsh, create a patch in the source rpm that adds
> an extra rc-file check that works like this:  If the user's rc file is
> missing, we read the default rc file from /usr/lib/zsh (or similar).



How would you check for modified default file? I mean, the sense is to 
get file automatically updated. You are allowed to do so only if user 
has not modified old file.

Well ... adding checksum to rc file may help. I.e. if there is a new 
default file and checksum is valid, replace it. Is becoming increasingly 
more complicated but it may work.


-andrej

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Bart Schaefer]

On May 21, 11:17am, Wayne Davison wrote:
> Subject: Re: Mandrake 8.0 - compinit in /etc/zshrc
> On 21 May 2001, Chmouel Boudjnah wrote:
> > and how do you do when you have to modify the skel file on upgrade ?
> 
> Here's an alternate solution.  See if you like this.
> 
> For a package such as zsh, create a patch in the source rpm that adds
> an extra rc-file check that works like this:  If the user's rc file is
> missing, we read the default rc file from /usr/lib/zsh (or similar).

It wouldn't be necessary to modify the source for that, would it?  The
last line of /etc/zshrc would just need to be:

[[ -r ${ZDOTDIR:-$HOME}/.zshrc ]] || source /usr/lib/zsh/power_options

This is basically the same as my function-based suggestion except that
you never create the ~/.zshrc file for the user.

} The only
} downside I see in this is that the user needs to be made aware that when
} they create their own rc file, that they may wish to copy the default rc
} file and modify that rather than starting from scratch.

Making them aware of that is the reason for creating their .zshrc with some
kind of comment embedded in it.  But it works passably either way.
-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Chmouel Boudjnah]

Wayne Davison <wayned@users.sourceforge.net> writes:

> For a package such as zsh, create a patch in the source rpm that adds
> an extra rc-file check that works like this:  If the user's rc file is
> missing, we read the default rc file from /usr/lib/zsh (or similar).


this could be a solution combined with Olivier suggetions we can do
something.. i'll see everything and post a suggetion of what we are
going to do for the packaging..

Re: [Cooker] RE: Mandrake 8.0 - compinit in /etc/zshrc

[Chmouel Boudjnah]

"Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru> writes:

> I like /etc/skel idea.

the problem is that /etc/skel/ thing break upgrade :-(

Re: Mandrake 8.0 - compinit in /etc/zshrc

[Trond Eivind Glomsrød]

Wayne Davison <wayned@users.sourceforge.net> writes:

> Add a .zshrc file to the /etc/skel dir that includes this compinit code.
> Then, add post-install code to the zsh rpm that gives a copy of this rc
> file to all existing users that don't already have the file (for a
> certain restricted definition of "all existing users"). 

Very bad idea. Very bad.

1) You can only do it once, and never fix it
2) Doing it this way makes it harder to run on multiple systems with
   multiple version of the program
3) Think of the scenario where one workstation with lots of home
   directories available (automounted when needed). Upgrading this one
   workstation would then try to "upgrade" all of the users,
   regardless of whether or not they use this machine at all

If you want to distribute configuration files this way, it should be
an active act of the sysadmin.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.