Re: [Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
Alexander Skwar <[EMAIL PROTECTED]> writes:
> Will 'LOAD_SYSTEM_ALIAS' be set by default? I would hope so, because if
yup.
> It's nice that a .alias file will be supported, but why should it *disable*
> loading of the system aliases?
> If a user figures out how to set aliases in the first place, is it really
> that far reached to assume that he'll also know about 'unalias'? If it's
> not (which I suppose), then I don't get why aliases shouldn't be put in
> /etc/profile.d/alias.sh
it's because in user home default we have no way to control the
files...
> Oh, BTW: Would it be possible to add /etc/profile.d/local.{sh,csh}, which
> should be empty files which also should never, ever be changed by an RPM
> upgrade? I think the mere existance of these files would make it clear to
> people/admins that only this file, and never /etc/profile should be used to
> adjust local settings.
nice idea..
Re: [Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
So sprach Chmouel Boudjnah am Tue, May 22, 2001 at 11:55:23AM +0100:
> yup but here we speak about default configuration of basic user. but
Understood. But, as you put it, 'basic users' will do neither. They won't
mess with their config files, I suppose. And especially for basic users,
I'd say that the fewer the user config files contain, the better. Because
if there's nothing in their config files, they cannot break anything.
># If exist a ~/.alias and the user hasn't specified a
># LOAD_SYSTEM_ALIAS variables then don't do any system aliases
Will 'LOAD_SYSTEM_ALIAS' be set by default? I would hope so, because if
not, it would mean that users might suddenly find themselves without aliases
set just because they (or whoever/whatever) created a file called .alias.
It's nice that a .alias file will be supported, but why should it *disable*
loading of the system aliases?
If a user figures out how to set aliases in the first place, is it really
that far reached to assume that he'll also know about 'unalias'? If it's
not (which I suppose), then I don't get why aliases shouldn't be put in
/etc/profile.d/alias.sh
> > I'd also think that /etc/skel should be nearly completely empty.
> > Everything should go into systemwide configuration files,
>
> yep normally but some thing need to let the user do it.
Parse error :) I think the current (?) /etc/skel/.bashrc is very nice:
# .bashrc
# User specific aliases and functions
if [ -f ~/.bash_alias ];then
. ~/.bash_alias
fi
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
That's what it should be like!
Oh, BTW: Would it be possible to add /etc/profile.d/local.{sh,csh}, which
should be empty files which also should never, ever be changed by an RPM
upgrade? I think the mere existance of these files would make it clear to
people/admins that only this file, and never /etc/profile should be used to
adjust local settings.
Alexander Skwar
--
How to quote: http://learn.to/quote (german) http://quote.6x.to (english)
Homepage: http://www.digitalprojects.com | http://www.iso-top.de
iso-top.de - Die günstige Art an Linux Distributionen zu kommen
Uptime: 8 days 7 hours 47 minutes
Re: [Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
Alexander Skwar <[EMAIL PROTECTED]> writes: > I somewhat disaggree. Some aliases like 'll' are used on many, many > different UNIX flavors and also mentioned in a lot of books, I suppose. > Users might expect this to be there. And if someone really does not want > the 'll' alias, he is always free to unalias it, isn't he? yup but here we speak about default configuration of basic user. but here is my update for aliases (at least for bourne shell) on mandrake : #If exist a ~/.alias and the user hasn't specified a #LOAD_SYSTEM_ALIAS variables then don't do any system aliases #If there is no ~/.alias but the user has specified a #IGNORE_SYSTEM_ALIASES then don't do any system aliases. > I'd also think that /etc/skel should be nearly completely empty. > Everything should go into systemwide configuration files, yep normally but some thing need to let the user do it. > as long as the user is able to override and disable it, as it is the > case with aliases. The same also applies for things like PATH, > EDITOR, etc.pp.. They should be setup with 'decent' (whatever that > is) values. agree.
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
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: [Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
So sprach Chmouel Boudjnah am Mon, May 21, 2001 at 07:27:24PM +0100: > 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 I somewhat disaggree. Some aliases like 'll' are used on many, many different UNIX flavors and also mentioned in a lot of books, I suppose. Users might expect this to be there. And if someone really does not want the 'll' alias, he is always free to unalias it, isn't he? I'd also think that /etc/skel should be nearly completely empty. Everything should go into systemwide configuration files, as long as the user is able to override and disable it, as it is the case with aliases. The same also applies for things like PATH, EDITOR, etc.pp.. They should be setup with 'decent' (whatever that is) values. Note though, that I say this, because the user *IS* able to disable the setting and/or modify it at will. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 7 days 8 hours 37 minutes
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
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
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
Wayne Davison <[EMAIL PROTECTED]> 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..
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
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
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
Andrej Borsenkow <[EMAIL PROTECTED]> 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..
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
Chmouel Boudjnah wrote: > Clint Adams <[EMAIL PROTECTED]> 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
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
Clint Adams <[EMAIL PROTECTED]> 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..
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
Clint Adams <[EMAIL PROTECTED]> 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.
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
Wayne Davison <[EMAIL PROTECTED]> 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: [Cooker] RE: Mandrake 8.0 - compinit in /etc/zshrc
"Andrej Borsenkow" <[EMAIL PROTECTED]> writes: > I like /etc/skel idea. the problem is that /etc/skel/ thing break upgrade :-(
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
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: [Cooker] RE: Mandrake 8.0 - compinit in /etc/zshrc
> > > > 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? > Not that I am aware of. That'd be pretty invasive. -- Geoffrey Lee <[EMAIL PROTECTED]> 李長風 http://www.wychk.org/~glee $ /usr/games/fortune Anything that can go wrong will go Segmentation fault (core dumped) $
[Cooker] RE: Mandrake 8.0 - compinit in /etc/zshrc
> > 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
[Cooker] Re: Mandrake 8.0 - compinit in /etc/zshrc
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
