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