From: "Bart Schaefer" <schaefer@brasslantern.com>
To: zsh-users@sunsite.auc.dk
Subject: Re: zsh startup files
Date: Sun, 28 Mar 1999 17:57:51 -0800 [thread overview]
Message-ID: <990328175751.ZM8402@candle.brasslantern.com> (raw)
In-Reply-To: <5logldgt3m.fsf@tequila.cs.yale.edu>
On Mar 28, 5:14pm, Stefan Monnier wrote:
} Subject: Re: zsh startup files
}
} >>>>> "Bart" == Bart Schaefer <schaefer@brasslantern.com> writes:
} > 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 ?
Let me first point out that none of this is interesting for non-interactive
shells. So when you later say:
} > (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'.
I say, so what? Only the two zshenv files are being sourced in that case
anyway.
} Could you give a (few) example(s) where the interleaving is beneficial ?
The canonical example of this being useful is terminal setup, which is
frequently done in /etc/profile on SVR4 systems (Motorola, Data General,
Olivetti, NCR, etc., where Bourne shell is often still the default shell)
and which a sysadmin is therefore likely to place in /etc/zprofile.
Settings in zshrc and zlogin (whether /etc/ or ~/.) may depend on correct
values of TERM, LINES, and COLUMNS; it's too late to fix them after the
entire system initialization has run (without duplicating the parts that
rely on them), but too early to fix them before /etc/zprofile.
I could come up with other examples, but they'd all be of that same shape.
Yes, in some cases it might be necessary to set your $path in .zshenv and
then set it again in .zlogin, or whatever. The point is that if you care
about what happens in between in /etc/z*, rather than simply wanting to
skip it entirely and do only your own stuff, then you need to get your
shot at it both before and after.
} It seems it just makes it easy to make changes that don't have the intended
} effect because other code is executed afterwards.
}
} 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.
I entirely agree that if what you want is for that other code to NOT run,
then the current startup file system is deficient. That's a different
issue from running the code in some other order.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1999-03-29 1:58 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
1999-03-29 1:57 ` Bart Schaefer [this message]
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=990328175751.ZM8402@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--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).