zsh-users
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier+lists/zsh/users/news/@tequila.cs.yale.edu>
To: zsh-users@sunsite.auc.dk
Subject: Re: zsh startup files
Date: 28 Mar 1999 17:14:05 -0500	[thread overview]
Message-ID: <5logldgt3m.fsf@tequila.cs.yale.edu> (raw)
In-Reply-To: <990327170423.ZM3271@candle.brasslantern.com>

>>>>> "Bart" == Bart Schaefer <schaefer@brasslantern.com> writes:
> The problem with this is that, for example, settings in /etc/zshrc may
> depend upon settings performed earlier.  The idea behind interleaving the
> user and system init files is so that, at each decision point in the
> system administrator's initialization chain, the user gets a chance to
> step in and change the details with his own initialization.

Sounds nice in theory, but how about practice ?
In my world, /etc/zshrc is normally designed to work in the environment setup
by /etc/zshenv and /etc/zprofile and if people add things in their ~/.zshrnv or
~/.zprofile, two things can happen: either the change is orthogonal to the
sysadmin's settings so there's no interaction, or there's some interaction and
it then tendfs to break the subsequent /etc/zshrc (or the /etc/zshrc just
undoes the~/.zprofile's settings).
Could you give a (few) example(s) where the interleaving is beneficial ?

> The order in which the files are sourced is designed to make it easy for
> a user who wants to make *minimal* changes to the system-wide defaults.
> If all I care about is changing one setting that's in /etc/zprofile, I

It seems it just makes it easy to make changes that don't have the intended
effect because other code is executed afterwards.

> If the ordering is as you just proposed, then in order to fix that one
> zprofile setting I may have to duplicate large sections of /etc/zshrc and
> /etc/zlogin in my .zshrc and .zlogin (or source them again, which might
> break in some other way).

Again a (few) example(s) of when this might happen would come in handy.
I never came across any such situation.

> make it work.  Many choices in the early days of zsh were made so that
> it would be easy for a novice, even if that made it noticably harder for
> an expert.

Ignoring NO_RCS after /etc/zshenv doesn't seem to make anything easier for
novices but does seem to make things much harder for the experienced user.

> (3) Use "exec" in .zshenv or .zprofile as I described above.

Note that this `exec' solution cannot be used for the case of commands
executed from `rsh'.


	Stefan


  reply	other threads:[~1999-03-28 22:25 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-03-24 22:48 Stefan Monnier
1999-03-24 23:15 ` Sweth Chandramouli
1999-03-25  0:47   ` Stefan Monnier
1999-03-25  5:53     ` Sweth Chandramouli
1999-03-25 11:17       ` Doug Morris
1999-03-25  2:20   ` Jason Price
1999-03-25  9:03 ` Peter Stephenson
     [not found]   ` <9903251002.AA18225@ibmth.df.unipi.it>
1999-03-25 10:55     ` Wolfgang Hukriede
1999-03-25 11:22       ` Peter Stephenson
1999-03-25 12:36         ` Stefan Monnier
1999-03-25 14:00           ` Peter Stephenson
1999-03-25 19:37             ` Stefan Monnier
1999-03-28  1:04               ` Bart Schaefer
1999-03-28 22:14                 ` Stefan Monnier [this message]
1999-03-29  1:57                   ` Bart Schaefer
1999-03-29  4:14                     ` Sweth Chandramouli
1999-03-29 14:15                     ` Stefan Monnier
1999-03-29 14:29                       ` Andrej Borsenkow
1999-03-31  7:14                         ` Bart Schaefer
1999-03-31  7:49                           ` Bart Schaefer
1999-04-02 13:12                           ` Stefan Monnier
1999-04-02 17:13                             ` Bart Schaefer
  -- strict thread matches above, loose matches on Subject: below --
2006-03-14 17:38 zzapper
2006-03-14 19:50 ` Wayne Davison
2006-03-15  2:43   ` Bart Schaefer
2006-03-15 18:22     ` Phil Pennock
2006-03-16 19:29     ` Dominic Mitchell
1996-10-19 23:04 Zsh " Nate Johnston
1996-10-20 11:09 ` Zefram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5logldgt3m.fsf@tequila.cs.yale.edu \
    --to=monnier+lists/zsh/users/news/@tequila.cs.yale.edu \
    --cc=zsh-users@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).