From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20026 invoked from network); 18 Jul 2000 05:23:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jul 2000 05:23:26 -0000 Received: (qmail 25154 invoked by alias); 18 Jul 2000 05:23:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12290 Received: (qmail 25146 invoked from network); 18 Jul 2000 05:23:15 -0000 From: "Bart Schaefer" Message-Id: <1000718052255.ZM22950@candle.brasslantern.com> Date: Tue, 18 Jul 2000 05:22:55 +0000 In-Reply-To: Comments: In reply to Zefram "PATCH: Re: adding a toplevel zsh.spec.in file" (Jul 18, 2:56am) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Zefram Subject: Re: PATCH: Re: adding a toplevel zsh.spec.in file Cc: zsh workers mailing list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jul 18, 2:56am, Zefram wrote: } Subject: PATCH: Re: adding a toplevel zsh.spec.in file } } And my suggestion for zsh-workers: let's get rid of /etc/z*. They're just } confusing things. /etc/profile is useful, the rest are just invitations } to tread on users' toes. So let's have zsh process /etc/profile first } thing (but only in a login shell), and not look at anything else in /etc. I'm fine with most things about this *except* the part about sourcing /etc/profile. I think it's quite sufficient that /etc/profile is read when zsh is emulating sh or ksh. Besides, sourcing /etc/profile effectively prevents a sysadmin from having any zsh-specific code in the global startups. I think that's going to have the exact opposite effect from what you want -- it's going to encourage admins to build zsh with the global RC files *enabled*, so that they can separate the zsh-specific stuff. However, I'm curious why you object to (e.g.) setting $PATH in /etc/zshenv. On systems where commands are installed in nonstandard places, why should every user's own .zshenv have to contain the settings that make rsh (and other noninteractive/nonlogin shells) find commands in the right places? } The only annoying thing left is that the global zprofile is run *after* } the user's .zshenv. Why is that annoying? The .zshenv is run on every shell, but the global zprofile is read only for login shells, and there's always the .zprofile and .zshrc files that are run after the global one. And then there's the recently-added NO_GLOBAL_RCS option, which can be set in .zshenv if the user is really picky. Which I suppose I could set to prevent /etc/profile from being read if it comes to that. Oh, no, it looks like you changed that, too; I VERY strongly object to that. } I suggest a configure option to support the current set of files, for } those few people that really do need them. In fact, configure already } has the right options, we just need to change their behaviour a bit. I predict that every system that currently ships with non-empy /etc/z* files will simply compile with these configs enabled, and continue to ship non-empty /etc/z* files. Obviously the maintainers of those environments believe that there's value in the settings they place in those files. A good example of this is the RedHat umask setting that Adam and I were just discussing. Since RedHat made the decision to put every user in a separate group -- something that baffles me to this day; maybe Trond is reading this and knows the reasoning -- it follows that they should set an appropriate umask, and that they'd prefer that umask to be set in as many shells as possible -- not just login shells, since may shells started e.g. in xterms are not login shells and may not even be started from within a login shell (consider xrsh or xon). } This really ought to be the other way round, to } match the usage of /etc/profile. It seems that a distinction must be } made between profile and zprofile. To match the usage of ... huh? To match WHAT usage of /etc/profile? The one when emulating ksh? That makes no sense, as the rest of the zsh startup series is not done when emulating ksh; you're comparing totally unrelated cases. -- 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