zsh startup files

zsh startup files

[Stefan Monnier]

Am I the only one that keeps getting annoyed by the sequence in which startup
files are read ?  It seems to be especially designed to make it easy for the
sysadmin to come up with a setup that is painful to override by users.
As a user and a syadmin who cares about users who like to override the
sysadmin's decisions, I think it should be changed.  Instead of something like

    /etc/zshenv ~/.zshenv /etc/zprofile ~/.zprofile /etc/zshrc ~/.zshrc ...

I suggest

    /etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin ~/.zshenv ~/.zprofile ...

This way the sysadmin can put in /etc/zprofile commands that should only be
executed at login time without having to worry about interference with the
user's ~/.zshenv settings.
And this way, when the sysadmin (or RedHat package maintainers) decide to put
bogus PATH and umask settings in /etc/zshrc it won't override my ~/.zprofile
choices.


	Stefan "pissed"

Re: zsh startup files

[Sweth Chandramouli]

On Wed, Mar 24, 1999 at 05:48:55PM -0500, Stefan Monnier wrote:
> 
> Am I the only one that keeps getting annoyed by the sequence in which startup
> files are read ?  It seems to be especially designed to make it easy for the
> sysadmin to come up with a setup that is painful to override by users.
> As a user and a syadmin who cares about users who like to override the
> sysadmin's decisions, I think it should be changed.  Instead of something like
> 
>     /etc/zshenv ~/.zshenv /etc/zprofile ~/.zprofile /etc/zshrc ~/.zshrc ...
> 
> I suggest
> 
>     /etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin ~/.zshenv ~/.zprofile ...
> 
> This way the sysadmin can put in /etc/zprofile commands that should only be
> executed at login time without having to worry about interference with the
> user's ~/.zshenv settings.
> And this way, when the sysadmin (or RedHat package maintainers) decide to put
> bogus PATH and umask settings in /etc/zshrc it won't override my ~/.zprofile
> choices.

	i think the idea is that the same sorts of commands will go in the
equivalent system-wide and user-specific files, so that by sourcing the
user files right after the relevant system files, the user can always override
the system options.  in other words, if your sysadmin is setting PATH and umask 
in /etc/zshrc, try setting it to your value in your own .zshrc instead of your 
.zprofile.  

	-- sweth.

-- 
Sweth Chandramouli
IS Coordinator, The George Washington University
<sweth@gwu.edu> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

Re: zsh startup files

[Stefan Monnier]

>>>>> "Sweth" == Sweth Chandramouli <sweth@astaroth.nit.gwu.edu> writes:
> 	i think the idea is that the same sorts of commands will go in the
> equivalent system-wide and user-specific files, so that by sourcing the user
> files right after the relevant system files, the user can always override the
> system options.  in other words, if your sysadmin is setting PATH and umask
> in /etc/zshrc, try setting it to your value in your own .zshrc instead of
> your .  .zprofile.

Which means:
1 - if my sysadmin is stupid and places things wrong, I have to do the same.
2 - that I can't use the same scripts on different systems.

And you're just giving me a workaround for the current situation, not
a justification for why it is that way in the first place.


	Stefan

Re: zsh startup files

[Jason Price]

>>    /etc/zshenv ~/.zshenv /etc/zprofile ~/.zprofile /etc/zshrc ~/.zshrc ...
>> I suggest
>>    /etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin ~/.zshenv ~/.zprofile ...

> i think the idea is that the same sorts of commands will go in the
> equivalent system-wide and user-specific files, so that by sourcing the
> user files right after the relevant system files, the user can always override
> the system options.  

I think the origional poster has a point.  Say you set something in
.zshenv that causes /etc/zshrc to break.  (Like blowing away $PATH)

Any thoughts?

Jason

-- 
"Do not confuse Repentance with Disgust: for one comes from the Landlord,
and the other is from the Enemy." --C.S. Lewis _The_Pilgrim's_Regress_
Jason Price	jprice@gatech.edu
Christian, Catholic, Sysadmin, Linux installer, Theta Xi, Atlanta-TEC.

Re: zsh startup files

[Sweth Chandramouli]

On Wed, Mar 24, 1999 at 07:47:31PM -0500, Stefan Monnier wrote:
> Which means:
> 1 - if my sysadmin is stupid and places things wrong, I have to do the same.
> 2 - that I can't use the same scripts on different systems.
> And you're just giving me a workaround for the current situation, not
> a justification for why it is that way in the first place.
	true on all counts.  i had vague memories of this coming up before,
and a quick search through the archives found a thread about this back in
95.  the basic issue there was the question of whether or not NO_RCS should
affect sourcing of /etc/zlogout; zoltan pointed out that by setting NO_RCS
in a user's ~/.zshenv, (s)he could avoid _all_ of the system init scripts
except for /etc/zshenv, and suggested changing the order the files were
sourced to the one you proposed.  i couldn't find any responses to that,
however, so i guess the topic was just dropped.  does anyone who was active
back then remember why?

	-- sweth.

-- 
Sweth Chandramouli
IS Coordinator, The George Washington University
<sweth@gwu.edu> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

Re: zsh startup files

[Peter Stephenson]

Stefan Monnier wrote:
> Am I the only one that keeps getting annoyed by the sequence in which startup
> files are read ?

No, it's a problem.  But getting it right is not that simple.
Compatibility is a major consideration, and every time something
significant like this changes, a great number of people are extremely
irritated; furthermore, sometimes it's useful for the user to get in
pre-emptively in ~/.zshenv before the remaining system files (no, I don't
want to explain).

One possibility is that we could allow an option to be set either on the
command line or in /etc/zshenv, so that all system files are run first.
Unfortunately I don't see a way of allowing a user to make a login shell
work this way, but if it's a question of how the system files are handled
maybe it's OK to leave it to the sysadmin.

How about the option name GLOBAL_RCS_FIRST and the letter -b (for begin, we
don't have many spare letters)?  It should be an easy patch for zsh 3.1.

To summarise: Invoking zsh -b, or calling `setopt GLOBAL_RCS_FIRST' in
/etc/zshenv, would force the order of scripts to be
  /etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin
  ~/.zshenv ~/.zprofile ~/.zshrc ~/.zlogin
As with the NO_RCS option, setting or unsetting the option at any later
point would have no effect.  The sysadmin could force all the global
scripts to be used before the user does anything.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: zsh startup files

[Wolfgang Hukriede]

Peter Stephenson <pws@ibmth.df.unipi.it> :

> Unfortunately I don't see a way of allowing a user to make a login shell
> work this way, but if it's a question of how the system files are handled
> maybe it's OK to leave it to the sysadmin.
...
> To summarise: Invoking zsh -b, or calling `setopt GLOBAL_RCS_FIRST' in
> /etc/zshenv, would force the order of scripts to be
>   /etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin
>   ~/.zshenv ~/.zprofile ~/.zshrc ~/.zlogin
> As with the NO_RCS option, setting or unsetting the option at any later
> point would have no effect.  The sysadmin could force all the global
> scripts to be used before the user does anything.

How about allowing the *user* to `setopt GLOBAL_RCS_FIRST' in their 
own ~/.zshenv; such that the order of script evaluation became:

 /etc/zshenv 
 ~/.zshenv (first chunk until `setopt GLOBAL_RCS_FIRST', then continue with ..)
 /etc/zprofile 
 /etc/zshrc 
 /etc/zlogin
 ~/.zshenv (rereading this one)
 ~/.zprofile 
 ~/.zshrc 
 ~/.zlogin

(Or maybe ~/.zshenv should be evaluated twice anyway.)

This way the *user* could "force all the global scripts to be used 
before the user does anything".

I thought, it was Stefans's concern to get liberated from the 
sysadmin's (or the sw distribution's) whims, not to donate them even
more power.

Greetings, Wolfgang.

Re: zsh startup files

[Doug Morris]

I can vaguely see a reason for this. The files are sourced
differently depending on the type of the shell being started. ie:

Always sourced
/etc/zshenv ~/.zshenv

Sourced for non-interactive login shells
/etc/zshenv ~/.zshenv /etc/zprofile ~/.zprofile /etc/zlogin ~/.zlogin

Sourced for interactive login shells
/etc/zshenv ~/.zshenv /etc/zprofile ~/.zprofile /etc/zshrc ~/.zshrc
/etc/zlogin ~/.zlogin

So it almost makes sense. You don't want the ~/.z* files waiting for
all the /etc/z* files to be sourced first. Still, this doesn't seem
like it would be too difficult to correct. The thing to do, though,
would be to change the order to:

Non-interactive Login shell
/etc/zshenv /etc/zprofile /etc/zlogin ~/.zprofile ~/.zshenv ~/.zlogin

Interactive Login Shell
/etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin ~/.zshenv ~/.zprofile
~/.zshrc ~/.zlogin 

I believe the diff below of init.c from zsh-3.0.5 will produce this
behavior. It appears to apply to zsh-3.1.5 as well, though I haven't
tried building it to make sure.


Since writing the above, I've received the list message from Peter
Stephenson <pws@ibmth.df.unipi.it> saying there may be a good reason
for leaving things alone. I guess this diff may or may not be useful.

However, I'd argue that, if you're going to make it a switchable
option. It should use this order by default, and the switch should
enable the old source order.  Maintaining backward compatibility is a
worthy plan, but I think correcting this odd order is better in the
long run and should be the default. The option should be provided to
allow people who need time to migrate their environment a temporary
workaround.


-Doug Morris 
"You don't have to deceive programmers to make them think that hours
 of painstaking, often frustrating work is fun... they do it to
 themselves."
 Noel Giffin, The Stone Soup Story


*** init.c.orig	Thu Mar 25 09:35:12 1999
--- init.c	Thu Mar 25 10:03:47 1999
***************
*** 744,770 ****
  	source(GLOBAL_ZSHENV);
  #endif
  	if (isset(RCS)) {
- 	    if (unset(PRIVILEGED))
- 		sourcehome(".zshenv");
- 	    if (islogin) {
  #ifdef GLOBAL_ZPROFILE
  		source(GLOBAL_ZPROFILE);
  #endif
- 		if (unset(PRIVILEGED))
- 		    sourcehome(".zprofile");
- 	    }
- 	    if (interact) {
  #ifdef GLOBAL_ZSHRC
  		source(GLOBAL_ZSHRC);
  #endif
- 		if (unset(PRIVILEGED))
- 		    sourcehome(".zshrc");
- 	    }
- 	    if (islogin) {
  #ifdef GLOBAL_ZLOGIN
  		source(GLOBAL_ZLOGIN);
  #endif
! 		if (unset(PRIVILEGED))
  		    sourcehome(".zlogin");
  	    }
  	}
--- 744,768 ----
  	source(GLOBAL_ZSHENV);
  #endif
  	if (isset(RCS)) {
  #ifdef GLOBAL_ZPROFILE
+ 	    if (islogin) 
  		source(GLOBAL_ZPROFILE);
  #endif
  #ifdef GLOBAL_ZSHRC
+ 	    if (interact) 
  		source(GLOBAL_ZSHRC);
  #endif
  #ifdef GLOBAL_ZLOGIN
+ 	    if (islogin) 
  		source(GLOBAL_ZLOGIN);
  #endif
! 	    if (unset(PRIVILEGED)) {
! 		sourcehome(".zshenv");
! 		if (islogin) 
! 		    sourcehome(".zprofile");
! 		if (interact)
! 		    sourcehome(".zshrc");
! 		if (islogin)
  		    sourcehome(".zlogin");
  	    }
  	}

Re: zsh startup files

[Peter Stephenson]

Wolfgang Hukriede wrote:
> Peter Stephenson <pws@ibmth.df.unipi.it> :
> 
> > To summarise: Invoking zsh -b, or calling `setopt GLOBAL_RCS_FIRST' in
> > /etc/zshenv, would force the order of scripts to be
> >   /etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin
> >   ~/.zshenv ~/.zprofile ~/.zshrc ~/.zlogin
> > As with the NO_RCS option, setting or unsetting the option at any later
> > point would have no effect.  The sysadmin could force all the global
> > scripts to be used before the user does anything.

(I've sent a patch for this, but the option has to be -d instead of -b,
since that turns out to mean `end of option processing' on the command
line.)

> How about allowing the *user* to `setopt GLOBAL_RCS_FIRST' in their 
> own ~/.zshenv

This makes things rather complicated; there's no fundamental difficulty,
but I'd prefer to keep it clean.  The idea is not that you're at war with
the sysadmin, who's supposed to make it easy for users to set their own
preferences.  But if this is popular enough...

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: zsh startup files

[Stefan Monnier]

>>>>> "Peter" == Peter Stephenson <pws@ibmth.df.unipi.it> writes:
> This makes things rather complicated; there's no fundamental difficulty,
> but I'd prefer to keep it clean.  The idea is not that you're at war with
> the sysadmin, who's supposed to make it easy for users to set their own
> preferences.  But if this is popular enough...

No.  /etc/zshrc is too often misused (and the "supposed" is of paramount
importance in the above sentence).
Actually, now that I think about it, why do we even need all those /etc/z*
files ?  It seems that all except for either /etc/zprofile or /etc/zshenv
should be kept empty in all but really unusual circumstances (in which case
you can still use zshenv for the same purpose).

I guess I could live with just NO_GLOBAL_RCS that I would
set in my .zshenv although it won't do me any good as a sysadmin.

Now, how can I simulate NO_GLOBAL_RCS (I don't want to wait for my
sysadmins to install a newer zsh version) ?

How can I determine from .zshenv whether or not .zshrc (and .zprofile)
would be sourced if NO_RCS wasn't set ?


	Stefan

Re: zsh startup files

[Peter Stephenson]

Stefan Monnier wrote:
> >>>>> "Peter" == Peter Stephenson <pws@ibmth.df.unipi.it> writes:
> > This makes things rather complicated; there's no fundamental difficulty,
> > but I'd prefer to keep it clean.  The idea is not that you're at war with
> > the sysadmin, who's supposed to make it easy for users to set their own
> > preferences.  But if this is popular enough...
> 
> No.

`No, this idea isn't popular', or `No, I am at war with the sysadmin who
doesn't make it easy'?

Various possibilities are

- set GLOBAL_RCS_FIRST by default in the next version; but whenever we do
something like that, something nasty happens.  True, it shouldn't hurt the
/etc/z* files which have to be able to run with no dot files in between,
but it could have some effect for dot files (can anyone produce an example?)

- make it available in the next version, and announce it may be set by
default in future, so that you should add `unsetopt GLOBAL_RCS_FIRST' to
/etc/zshenv if you really don't want it.

> Actually, now that I think about it, why do we even need all those /etc/z*
> files ?  It seems that all except for either /etc/zprofile or /etc/zshenv
> should be kept empty in all but really unusual circumstances (in which case
> you can still use zshenv for the same purpose).

Potentially, they may be useful, but I certainly agree they're overused and
often abused.  On this system here, we have /etc/zprofile, /etc/zshenv and
/etc/zshrc --- and they're almost identical.

> I guess I could live with just NO_GLOBAL_RCS that I would
> set in my .zshenv although it won't do me any good as a sysadmin.

(Do you mean GLOBAL_RCS_FIRST, or are you proposing a different option for
not running global scripts apart from /etc/zshenv at all?)  If it worked in
.zshenv, it would certainly be made to work in /etc/zshenv: the question
would be whether it should have an effect in .zshenv as well.

> Now, how can I simulate NO_GLOBAL_RCS (I don't want to wait for my
> sysadmins to install a newer zsh version) ?

Again, if you mean, `how do I get all my code to run after the global
scripts have finished', then I can't see any problem with the following,
but I haven't tried it out, so I may have missed something.  I've relied on
the fact that .zshrc is run for any interactive shell (option interactive
is set), and .zprofile and .zlogin for any login shell (option login set),
and that a login shell is always interactive.  That should answer your
other question.

1. Move .zshenv, .zprofile, .zshrc, .zlogin to .real_zshenv,
.real_zprofile, etc, etc.

2a. In .zshenv:

if [[ ! -o interactive ]]; then
  [[ -f ~/.real_zshenv ]] && source ~/.real_zshenv
fi

2b. Delete .zprofile

2c. In .zshrc:

if [[ ! -o login ]]; then
  [[ -f ~/.real_zshrc ]] && source ~/.real_zshrc
fi

2d. In .zlogin:

[[ -f ~/.real_zshenv ]] && source ~/.real_zshenv
[[ -f ~/.real_zprofile ]] && source ~/.real_zprofile
[[ -f ~/.real_zshrc ]] && source ~/.real_zshrc
[[ -f ~/.real_zlogin ]] && source ~/.real_zlogin

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: zsh startup files

[Stefan Monnier]

>>>>> "Peter" == Peter Stephenson <pws@ibmth.df.unipi.it> writes:
> `No, this idea isn't popular', or `No, I am at war with the sysadmin who
> doesn't make it easy'?

I meant: no, the sysadmin(s) often just refuse changing something that
(they claim) works.  The mere fact that it makes user-configs clunky is
nor considered important enough to take the risk of screwing up something
in the config.  Furthermore, they generally aren't even able to understand
what the problem is and will give you answers like "well, with our default
config I couldn't reproduce your problem".

> Potentially, they may be useful, but I certainly agree they're overused and
> often abused.  On this system here, we have /etc/zprofile, /etc/zshenv and
> /etc/zshrc --- and they're almost identical.

Given my above description, I think software should always make it hard
for the sysadmin to screw up and abuse a config.  Currently, zsh tends to
encourage such abuse (for instance /etc/zshrc should always be replaced by
a `source /etc/user/zshrc' in the /etc/skel/.zshrc file so that the user
is given the choice to turn it off or call it at some other time).

>> I guess I could live with just NO_GLOBAL_RCS that I would
>> set in my .zshenv although it won't do me any good as a sysadmin.
> (Do you mean GLOBAL_RCS_FIRST, or are you proposing a different option for
> not running global scripts apart from /etc/zshenv at all?)  If it worked in.

I'm proposing a new option.

> .zshenv, it would certainly be made to work in /etc/zshenv: the question
> would be whether it should have an effect in .zshenv as well.

I think that any such flag should just take effect immediately, no matter
when it is set.  `setopt norcs' if executed in .zshrc should prevent
/etc/zlogin and .zlogin from being executed.

> Again, if you mean, `how do I get all my code to run after the global
> scripts have finished', then I can't see any problem with the following,
> but I haven't tried it out, so I may have missed something.  I've relied on
> the fact that .zshrc is run for any interactive shell (option interactive
> is set), and .zprofile and .zlogin for any login shell (option login set),
> and that a login shell is always interactive.  That should answer your
> other question.

I was thinking of using something more like

    % cat .zshenv
    ...
    ...blabla...
    ...
    setopt norcs
    [[ -o login ]] && source .zprofile
    [[ -o interactive ]] && source .zshrc
    [[ -o login ]] && source .zlogin
    %

Sadly, it seems that `setopt norcs' only takes effect in /etc/zshenv.
Why was that deemed desirable ?
How can I prevent /etc/zshrc from being sourced for interactive shells.


	Stefan

Re: zsh startup files

[Bart Schaefer]

This has certainly been an interesting discussion; I'm sorry I wasn't able
to join in sooner.

There was a similar discussion a long time ago when /etc/z* were first
added.  I tried to find it, but my personal archive of the old zsh-list
has a gap from message 399 to something in the 1100s, and the zsh.org
archive goes back only to 1995.

On Mar 24,  5:48pm, Stefan Monnier wrote:
} Subject: zsh startup files
}
} Am I the only one that keeps getting annoyed by the sequence in which
} startup files are read?  It seems to be especially designed to make
} it easy for the sysadmin to come up with a setup that is painful to
} override by users.

There are a couple of things about it that bother me, but the order in
which they're read is not one of them.  I've felt for a long time that a
user ought to be able to `setopt NO_RCS` at any point in his startup
files and effectively shut off all later startup files (both his own and
the system ones).

I asked about this twice way back in zsh-workers 1393 and 1414, and
never got an answer as to why it works the way it does.

(The current situation is that `setopt NO_RCS` works only in /etc/zshenv
or on the command line, *except* that setting it at *any* time disables
both /etc/zlogout and .zlogout.)

} I suggest
} 
} /etc/zshenv /etc/zprofile /etc/zshrc /etc/zlogin ~/.zshenv ~/.zprofile ...

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.

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
put that change in my .zprofile, and I don't have to worry about missing
or redoing any of the system initialization that precedes or follows it.

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).

On Mar 24,  7:47pm, Stefan Monnier wrote:
} Subject: Re: zsh startup files
}
} Which means:
} 1 - if my sysadmin is stupid and places things wrong, I have to do the same.
} 2 - that I can't use the same scripts on different systems.
} 
} And you're just giving me a workaround for the current situation, not
} a justification for why it is that way in the first place.

Yes, this makes things a bit annoying if you want to transport your same
zsh enviroment among many systems with different sysadmins' ideas about
what should be in the /etc/z* files.  The assumption made was that, if
you're doing that, you're an experienced user who can figure out how to
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.

I'm not sure whether I can say we're still holding to that philosophy.

On Mar 24,  9:20pm, Jason Price wrote:
} Subject: Re: zsh startup files
}
} I think the origional poster has a point.  Say you set something in
} .zshenv that causes /etc/zshrc to break.  (Like blowing away $PATH)
} 
} Any thoughts?

This is the reason that sourcing of init scripts in general tries to
fail gracefully, without kicking you out of the shell.  So that if you
do something silly like that, you'll still be able to log in and fix it.
There IS a discussion about this in the zsh-workers archive.

On Mar 25, 12:53am, Sweth Chandramouli wrote:
} Subject: Re: zsh startup files
}
} ... a quick search through the archives found a thread about this back
} in 95. the basic issue there was the question of whether or not NO_RCS
} should affect sourcing of /etc/zlogout; zoltan pointed out that by
} setting NO_RCS in a user's ~/.zshenv, (s)he could avoid _all_ of the
} system init scripts except for /etc/zshenv

Actually, it's by setting NO_RCS on the *command line* that this is
possible, in which case you also avoid your own .zshenv.  It can't be
done trivially from .zshenv.

On Mar 25, 10:03am, Peter Stephenson wrote:
} Subject: Re: zsh startup files
}
} One possibility is that we could allow an option to be set either on the
} command line or in /etc/zshenv, so that all system files are run first.

I'm a little sorry that you've already posted pws-14 with this change
included, because I think some modification of the handling of NO_RCS
would be a much more general solution.

The change in your patch is of no benefit to a sysadmin; the equivalent
effect can be gained by adding a few lines to /etc/zshenv, one of which
is `setopt norcs`.  It is of only minimal benefit to users, because (as
you pointed out) they can't make it happen for login shells anyway.

On the other hand, leaving the order of init files alone yet testing
NO_RCS more often -- even if only both before and after .zshenv is read
-- gives the user control over the process without taking away anything
that the sysadmin can accomplish now.

On Mar 25, 11:55am, Wolfgang Hukriede wrote:
} Subject: Re: zsh startup files
}
} How about allowing the *user* to `setopt GLOBAL_RCS_FIRST' in their 
} own ~/.zshenv

Why .zshenv?  Why not anywhere along the way?

On Mar 25, 12:17pm, Doug Morris wrote:
} Subject: Re: zsh startup files
}
} However, I'd argue that, if you're going to make it a switchable
} option. It should use this order by default, and the switch should
} enable the old source order.  Maintaining backward compatibility is a
} worthy plan, but I think correcting this odd order is better in the
} long run and should be the default.

I disagree that the old order was wrong, for the reasons above.

On Mar 25,  7:36am, Stefan Monnier wrote:
} Subject: Re: zsh startup files
}
} Actually, now that I think about it, why do we even need all those /etc/z*
} files ?

That's why reading them can be compiled out as an option.  In one recent
case where I thought the system /etc/z* files were a mess, I simply built
my own copy of zsh with the global RCs turned off, and exec'd that from
my own .zshenv, passing along the command line args.  (After exporting a
new ZDOTDIR so the same .zshenv would not be read a second time.)

} Now, how can I simulate NO_GLOBAL_RCS (I don't want to wait for my
} sysadmins to install a newer zsh version) ?

For one way, see above.

} How can I determine from .zshenv whether or not .zshrc (and .zprofile)
} would be sourced if NO_RCS wasn't set ?

By testing [[ -o interactive ]] and [[ -o login ]].  PWS's example is a
bit more detailed.

On Mar 25,  3:00pm, Peter Stephenson wrote:
} Subject: Re: zsh startup files
}
} - set GLOBAL_RCS_FIRST by default in the next version; but whenever we
} do something like that, something nasty happens. True, it shouldn't
} hurt the /etc/z* files which have to be able to run with no dot files
} in between, but it could have some effect for dot files (can anyone
} produce an example?)

If the hypothetical situation I described above isn't enough to convince
you, I'll try to come up with an actual sequence of events that would be
a problem.

} - make it available in the next version, and announce it may be set by
} default in future, so that you should add `unsetopt GLOBAL_RCS_FIRST'
} to /etc/zshenv if you really don't want it.

If you still think there'd ever be a reason for this to become default
behavior, then I still think you're solving the wrong problem.

On Mar 25,  2:37pm, Stefan Monnier wrote:
} Subject: Re: zsh startup files
}
} How can I prevent /etc/zshrc from being sourced for interactive shells.

(1) Run "zsh -f".  Has obvious unwanted side effects.
(2) Run zsh from a link named "ksh".  Has obvious unwanted side effects.
(3) Use "exec" in .zshenv or .zprofile as I described above.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh startup files

[Stefan Monnier]

>>>>> "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

Re: zsh startup files

[Bart Schaefer]

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

Re: zsh startup files

[Sweth Chandramouli]

On Sun, Mar 28, 1999 at 05:57:51PM -0800, Bart Schaefer wrote:
> } 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.
	what this issue really gets down to is portability and ease of use;
the current interleaving of system and user init files makes the task of
writing init files much more complicated than it should be, and the task of
writing portable ones even more difficult.  in pretty much every other
programming environment that i can think of (and, when you get down to it,
the shell _is_ just a programming environment), you are guaranteed that,
although there might be system-wide defaults and settings, once the user
is given control of his/her environment, any changes he/she makes won't
subsequently be clobbered by the system; in zsh, however, the interleaving
of init files means that at every stage of the init process, the user has
to be aware (and wary) of the system configurations--both their end effect,
which most programmers have to deal with, and the process by which that
effect is achieved, which most other environments don't require.
	the problems go both ways, for that matter--the sysadmin has no
way of being assured, with the current setup, that a user won't do something
in a user init file that will break all of the subsequent system init files.
the example bart gave of term settings in /etc/zprofile doesn't really parse,
for this very reason--the only reasonable times that the interleaving will
make term settings work instead of breaking them are those when the system
init files _won't_ work unless the user init files make certain changes.

> 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.
	the question isn't whether or not the other code should run at all;
it's whether or not the other code should be able to, in running, change
the environment of the user midstream.

	the one way that interleaving the init files could be helpful, as far
as i can see, would be if NO_RCS were relevant anywhere in the init process,
as bart has suggested before--then, a user could halt the init process, say,
after the zlogin files (both system and user) had run, but before any of the
zshrc files were sourced.  that seems of less value to me, however, than
being able to create init files that don't have to be carefully rechecked
every time the "other person" (the admin if you are a user, or the user if
you are an admin) makes a change.
	the best-of-both-worlds solution, i guess, would be a solution that
let the user choose between either model, and which (for compatibility reasons)
defaulted to the current model (but which would eventually migrate to the
all-system-inits, then all-user-inits model).  the best way i can think of
to implement this would be to make five "special" arrays (ENV_INITS, 
LOGIN_INITS, RC_INITS, PROFILE_INITS, and LOGOUT_INITS) which by default (for
a login shell--non-login interactive shells and non-interactive shells, 
would have different values, obviously), the values of these arrays would be 
set to (/etc/zshenv ~/.zshenv), (/etc/zlogin ~/.zlogin), (/etc/zshrc ~/.zshrc),
(/etc/zprofile ~/.zprofile), and (/etc/zlogout ~/.zlogout).  then, i would
add an option (SEQUENTIAL_INITS) that defaults to a value of ON, and
which could be changed at any time.  at every "init file checkpoint" (defined
as the moment when init files would first be sourced normally, and then after
every init file is subsequently sourced), then, the value of SEQUENTIAL_INITS 
would be checked.  if it were ON, then the first value in the next special
array (proceeding through the arrays in the order listed above) would be 
"popped" out of the array, and the relevant file sourced; if the array in
question were empty, then the next array in order would be checked.  if 
SEQUENTIAL_INITS were OFF, however, then after "popping" the value off one
of the init arrays, the first value of the _next_ array would be popped,
wrapping around to the beginning once PROFILE_INIT was reached.  (LOGOUT_INIT
would not be part of either scenario, instead only being checked on logout,
obviously.)
	with this sort of solution, by default the current behaviour would
be maintained.  any user could, however, in their ~/.zshenv `unsetopt
SEQUENTIAL_INITS', and then reset the init arrays to just contain their
user init files; the only system init file that would be sourced in this
scenario, then, would be /etc/zshenv.  the NO_RCS option could then be
redefined to mean that all init arrays would be cleared if that option were
set in one of the files referenced in ENV_INITS, or just LOGOUT_INITS
would be cleared if that option were set anywhere else; this should duplicate
the current NO_RCS behaviour, while letting people like bart (and myself)
who would rather have NO_RCS take effect whenever it is set could just
change the values of the init arrays directly.

	this is just a quick off-the-cuff solution idea; i'm sure others can 
come up with good modifications.  (and someone would have to implement it, of 
course; i'm staring at my "practical c programming" book and wondering how
long it would take to get up to speed with c.)

	-- sweth.

-- 
Sweth Chandramouli
IS Coordinator, The George Washington University
<sweth@gwu.edu> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

Re: zsh startup files

[Stefan Monnier]

> } 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.

Good point.

> 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.

[ passing note:  if someone could tell me in which case terminal setup
  is useful, I'd be happy to learn.  I've never needed any such thing.
  I thought it was because I only use xterm terminals, but now that I have
  a dumb-terminal plugged into my workstation, I have to revise this
  judgment.  Maybe the terminal setup is only unnecessary for xterm and
  vt220-compatible (i.e. for vt100-style) terminals ? ]

> 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.

Could you give examples of zshrc (zlogin is irrelevant to me: you either use
zlogin or zprofile, not both) settings that might depend on TERM/LINES/COLUMNS?
Also, if the sysadmin's files require changes in .zprofile for /etc/zshrc to
work properly, it just means that /etc/zprofile (or /etc/zshrc) is somewhat
bogus.  It seems more likely that /etc/zshrc works properly when executed
straight after /etc/zprofile and the .profile might break it.

> 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.

The /etc/z* files should be *minimal*.  Anything that is not strictly
necessary should be moved to /etc/user/foo and explicitly sourced from ~/.z*
(themselves inherited from /etc/skel/.z*).  This gives the user and the
sysadmin much more freedom and flexibility than the default complex sequence.

> 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.

Actually, the ability to use NO_RCS is really all I need since I can then
manually source the files I want in the order I want.
The complex setup suggested by Sweth seems unwarranted and cumbersome.
The only problem with NO_RCS is the logout files, so adding a variable
holding the files to be executed at logout is all that's needed.


	Stefan

RE: zsh startup files

[Andrej Borsenkow]

>
> [ passing note:  if someone could tell me in which case terminal setup
>   is useful, I'd be happy to learn.

Our tty driver defaults to DEL for interrupt. Some of our terminals
(notably, vt-like ones) don't have DEL at all (they have Delete that sends
escape sequence). So, intr is remapped to ^C for such terminals.
>
> Could you give examples of zshrc (zlogin is irrelevant to me: you
> either use
> zlogin or zprofile, not both) settings that might depend on
> TERM/LINES/COLUMNS?

Setting truncation for {R,L}PROMPT. I'd probably would like to set this for
all interactive shells (if at all), and for this reasin this should go into
zshrc. Setting bold/standout etc attrs (depending on which is uderstood by
terminal). Resetting of some terminal attrs in precmd (in our case, FMLI
resets am attr if terminal has capabillity to do it. It leads to all sorts
of side effects, as all programs expect, that if am is listed, it is set
-( Hey, I can imagine binding to func keys as well.

>
> The /etc/z* files should be *minimal*.  Anything that is not strictly
> necessary should be moved to /etc/user/foo and explicitly sourced
> from ~/.z*

Entirely agreed.

cheers

/andrej

Re: zsh startup files

[Bart Schaefer]

On Mar 28, 11:14pm, Sweth Chandramouli wrote:
} Subject: Re: zsh startup files
}
} [...] in pretty much every other programming environment that i
} can think of (and, when you get down to it, the shell _is_ just a
} programming environment), you are guaranteed that, although there
} might be system-wide defaults and settings, once the user is given
} control of his/her environment, any changes he/she makes won't
} subsequently be clobbered by the system [...]

A shell isn't really a programming environment.  People use shells all
the time for things that aren't even remotely related to programming.

If you want an example of an even more convoluted initialization system
that even more people use even more heavily than zsh, I need only point
you to emacs.

Of course, by that example, perhaps we DO need to encourage sysadmins to 
_properly_ install /etc/z*, by providing same (not the current examples)
with instructions as to what properly goes (or does not) in each.  Emacs
is saved from insanity by delivering its runtime system pre-packaged.

} the example bart gave of term settings in /etc/zprofile doesn't really
} parse, for this very reason--the only reasonable times that the
} interleaving will make term settings work instead of breaking them are
} those when the system init files _won't_ work unless the user init
} files make certain changes.

You're at least partly right about that, although "won't work" is less
often the case than "work but leave annoying glitches."  Examples from
my own experience include "benign" mislabelings of the terminal like
vt100 when it should be vt220, or (one I'm currently wrangling with)
correctly choosing "xterm" but having significantly different versions
of X on the display server than on the login server, such that reverse
video doesn't go on/off properly using the login server's terminfo.

} [...] if NO_RCS were relevant anywhere in the init process,
} [...]  that seems of less value to me, however, than
} being able to create init files that don't have to be carefully rechecked
} every time the "other person" (the admin if you are a user, or the user if
} you are an admin) makes a change.

Unless your personal init files do _all_ necessary setup, as if /etc/z*
were empty, you're going to have to recheck them in any case.  And if
you do completely supercede the system files, then having the system
files sourced at all is, at best, a waste of time.

} 	the best-of-both-worlds solution, i guess, would be
[exceptionally baroque suggestion deleted]

Any system which attempted to provide that level of control is (1) even
harder to use than the corresponding `if [[ -o ... ]]; then ... fi` and
(2) an open invitation to a sysadmin to use /etc/zshenv to set the order
to what he likes and then typeset the corresponding variables read-only.
The result is even less portable/predictable than before!

On Mar 29,  9:15am, Stefan Monnier wrote:
} Subject: Re: zsh startup files
}
} > 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.
} 
} Could you give examples of zshrc settings that might depend on
} TERM/LINES/COLUMNS?

Sure.  One, I set up the $LESS environment in zshrc, with z$[LINES-2] (set
scroll height to two less than $LINES).  Two, I used to have a multi-line
$PS1, which I also set in zshrc, that depended on $COLUMNS, and that was
not used at all when the terminal was "emacs" or "dumb".  Three, I played
for a while with different .exrc files for fast and slow connections; I
set up $EXINIT based on the terminal type (yes, that's what $BAUD is for,
but it was wrong for other reasons, and passing extra data through rlogin
by stuffing it into $TERM and then parsing it out again is a time-honored
hack).  All these go in zshrc because they're useless to non-interactive
shells, but sometimes necessary even in non-login ones (think "su" if
nothing else).

The interleaving of init files let me get away with that last one, because
I could demangle $TERM in my .zshenv before /etc/zprofile ran.  A system
administrator might be as likely to put the other two in /etc/zshrc as I
was to put them in .zshrc, so if I can jump in at .zshenv or .zprofile
and make sure the terminal setup is OK, I'm happier.

Of course at this point (cf. the "exec" trick) I'm more likely to want to
bypass the system files entirely, but that wasn't always the case, and
sometimes isn't worth bothering with (I was just at a consulting job
where the /etc/z* files did extensive environment setup for a collection
of homegrown custom build tools; it would have been silly to try to redo
it or reorder it).

} The /etc/z* files should be *minimal*.  Anything that is not strictly
} necessary should be moved to /etc/user/foo and explicitly sourced from
} ~/.z* (themselves inherited from /etc/skel/.z*).

Back when I was at OGI, the login banner had to announce that any user
whose .login was found _not_ to contain a certain set of commands, would
lose their access to the system.  Boy, would it have been simpler for all
concerned if csh had always read an /etc/csh.login back then.  (And guess
what tcsh does now?  And guess in what order WRT the user's .cshrc?)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh startup files

[Bart Schaefer]

On Mar 30, 11:14pm, Bart Schaefer wrote:
} Subject: Re: zsh startup files
}
} [...] Boy, would it have been simpler for all concerned if csh had
} always read an /etc/csh.login back then. (And guess what tcsh does
} now? And guess in what order WRT the user's .cshrc?)

Before someone else corrects me ... I just noticed that tcsh reads both
of the /etc/csh* files first.  My recollection had been that it was
interleaved like zsh, and that this is where the idea for zsh's system
came from ... but if it ever was, it's not any more for tcsh.

That doesn't change my opinion, but I'll grant that it's a data point
in favor of untangling them.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh startup files

[Stefan Monnier]

>>>>> "Bart" == Bart Schaefer <schaefer@brasslantern.com> writes:
> If you want an example of an even more convoluted initialization system
> that even more people use even more heavily than zsh, I need only point
> you to emacs.

I beg to disagree.  Emacs's initialization is quite a bit simpler:

    site-lisp/site-start.el ~/.emacs site-lisp/default.el

three simple steps where the last one can be disabled in either
of the first two.

> Sure.  One, I set up the $LESS environment in zshrc, with z$[LINES-2] (set
> scroll height to two less than $LINES).  Two, I used to have a multi-line
> $PS1, which I also set in zshrc, that depended on $COLUMNS, and that was
> not used at all when the terminal was "emacs" or "dumb".  Three, I played
> for a while with different .exrc files for fast and slow connections; I
> set up $EXINIT based on the terminal type (yes, that's what $BAUD is for,
> but it was wrong for other reasons, and passing extra data through rlogin
> by stuffing it into $TERM and then parsing it out again is a time-honored
> hack).  All these go in zshrc because they're useless to non-interactive
> shells, but sometimes necessary even in non-login ones (think "su" if
> nothing else).

These sound like ad-hoc hacks that more or less work in some specific cases.
Very far from the kind of things you'd want to put in /etc/zshrc.

> The interleaving of init files let me get away with that last one, because
> I could demangle $TERM in my .zshenv before /etc/zprofile ran.  A system

The $TERM mangling is an interesting case.  I'd tend to say that if
a /etc/zprofile or /etc/zshenv doesn't work with such a thing, it's broken.
It might work suboptimally, tho.

> Of course at this point (cf. the "exec" trick) I'm more likely to want to
> bypass the system files entirely, but that wasn't always the case, and
> sometimes isn't worth bothering with (I was just at a consulting job
> where the /etc/z* files did extensive environment setup for a collection
> of homegrown custom build tools; it would have been silly to try to redo
> it or reorder it).

So you agree in a sense:  this fancy ordering is sometimes useful,
but when it is, other alternatives would work as well.

> Back when I was at OGI, the login banner had to announce that any user
> whose .login was found _not_ to contain a certain set of commands, would
> lose their access to the system.

I'm all for a /etc/zshenv or maybe even more init files (as a sysadmin
I really like to setup some envvars in there), but that has no relation to
whether these should be sourced in such an interleaved manner.


	Stefan

Re: zsh startup files

[Bart Schaefer]

On Apr 2,  8:12am, Stefan Monnier wrote:
} Subject: Re: zsh startup files
}
} >>>>> "Bart" == Bart Schaefer <schaefer@brasslantern.com> writes:
} > If you want an example of an even more convoluted initialization system
} > that even more people use even more heavily than zsh, I need only point
} > you to emacs.
} 
} I beg to disagree.  Emacs's initialization is quite a bit simpler

Superficially, you're correct.  In practice, every autoloaded feature
does its own initialization at the time it's loaded, and any serious
user employs numerous hook functions and eval-after-load and so on to
interleave his own adjustments to that intialization.

Even for the simple case, though, there's system init both before and
after ~/.emacs ... but you can disable the "after" one, which is what
I've been saying should be possible with zsh too.

} > Sure.
} 
} These sound like ad-hoc hacks that more or less work in some specific cases.
} Very far from the kind of things you'd want to put in /etc/zshrc.

I agree about the EXINIT one.  Changing the prompt or $LESS is something
a sysadmin might do, even if you think he shouldn't.

} So you agree in a sense:  this fancy ordering is sometimes useful,
} but when it is, other alternatives would work as well.

What I disagree with about that is the "as well."  They'd work *also*,
but not *as well*.

} I'm all for a /etc/zshenv or maybe even more init files

Please, not more.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: zsh startup files

[Dominic Mitchell]

Bart Schaefer wrote:
> Back when I was using timeshared computers a lot, I had a .zlogout that
> cleared the screen and any scrollback buffers, but I removed that a long
> time ago; I haven't thought of any other good use for it.

I've found it necessary to use .zlogout to kill my ssh-agent.  This was 
under cygwin though.  :-)

-Dom

Re: zsh startup files

[Phil Pennock]

On 2006-03-14 at 18:43 -0800, Bart Schaefer wrote:
> Back when I was using timeshared computers a lot, I had a .zlogout that
> cleared the screen and any scrollback buffers, but I removed that a long
> time ago; I haven't thought of any other good use for it.

Machine-rooms in third-party hosting facilities, when you've been in
logged in on a real virtual console.

I should probably get around to making it more portable to different TTY
naming schemes, but the very simple method works for me:
[[ $SHLVL -eq 1 && $TTY == /dev/ttyv* ]] && clear

Re: zsh startup files

[Bart Schaefer]

On Mar 14, 11:50am, Wayne Davison wrote:
}
} I moved all my non- interactive variable settings into ~/.zprofile (my
} interactive settings have always been in ~/.zshrc) and I reduced the
} ~/.zshenv file to these 3 lines:

My .zshenv is only two lines:

export ZDOTDIR=$HOME/.zsh
. $ZDOTDIR/.zshenv

OK, so that's cheating.

$ZDOTDIR/.zshenv has 7 lines of variable assignments so that all the
variables that were ever set by zsh (back as far as about version 2.1)
have the values they would have in whatever version that was, so that
my 15 years (gah) of accumulated zsh configuration doesn't have to be
rewritten, only added-to.  (If I haven't got around to forward-porting
it by now, it's never going to happen.)  Then it sets $path, $fpath and
a few other environment variables read from a second file that I edit
for each specific machine, so that I can just copy around all the rest
of the configuration.  (I keep it in cvs and just "cvs co" it when I
get an account in a new place.)

The only job of $ZDOTDIR/.zprofile is to search $path to be sure that,
if more than one version of zsh is found in $path, everything refers to
the most recent possible version.  If necessary it execs that zsh.

$ZDOTDIR/.zshrc sets up options, prompt strings, aliases, bindkeys,
completion, xterm title, and history.

$ZDOTDIR/.zlogin sets up the tty driver, ssh agent if it isn't yet, and
anything interactive left over from .zshrc, like $mailpath.

Back when I was using timeshared computers a lot, I had a .zlogout that
cleared the screen and any scrollback buffers, but I removed that a long
time ago; I haven't thought of any other good use for it.

Re: zsh startup files

[Wayne Davison]

On Tue, Mar 14, 2006 at 05:38:37PM +0000, zzapper wrote:
> I've got everything in my ~/.zshenv can I do better?

Doing this means that you can't override anything that is set in the
.zshenv file and have it affect another zsh script or indeed any command
that was spawned using $SHELL (which affects a lot of commands that run
other commands, such as gdb).  Because of this, I moved all my non-
interactive variable settings into ~/.zprofile (my interactive settings
have always been in ~/.zshrc) and I reduced the ~/.zshenv file to these
3 lines:

if [[ $SHLVL == 1 && ! -o LOGIN ]]; then
    source ~/.zprofile
fi

The overall idea is that I want these variables to be set once, and then
inherited from then on.  The reason for the above 3 lines is that some X
windows environments don't start a login shell for an xterm, so this
code makes sure that a top-level shell that is not a login shell still
includes the zprofile information that would have been included
automatically by a login shell.  If you have other settings that you
always want to be forced into a certain state regardless of the parent
environment, you could set them there as well.

..wayne..

zsh startup files

[zzapper]

Hi,
At the risk of exposing my ignorance, I think there's a concept of multi-
level startup files of type .z* such that ideally you don't have rerun all 
your setup every time you run say a small 3 line script.

I've got everything in my ~/.zshenv can I do better?


-- 
http://successtheory.com/ 100 FREE Success and Self-Improvement Tips

Re: Zsh startup files

[Zefram]

>Is there any real difference in the function of .zprofile, .zshrc, etc?  

Yes.  .zprofile and .zlogin are used only by login shells, .zshenv is
sourced by all shells, and .zshrc is used only by interactive shells.
Roughly speaking, .zshenv should set up aliases, environment variables
and emulation-relevant options; .zshrc should do compctls and other
options; and .z(profile|login) should do tty settings, motd display and
so on.

>* How would I program a prompting mechanism, i.e. put up a prompt and wait
>for input that would be put into an env var in a script?  The "read"
>documentation is unclear and I can't figure it out.

read 'foo?prompt: '

-zefram

Zsh startup files

[Nate Johnston]

Hi there.  I'm something of a beginning user, so I am not entirely sure
if this is the correct forum for this question.  But I have two.

* my .zshenv contains things that will be used in all of my scripts and
shells, and the rest of the startup files seem only to be used for shells.
Is there any real difference in the function of .zprofile, .zshrc, etc?  

* How would I program a prompting mechanism, i.e. put up a prompt and wait
for input that would be put into an env var in a script?  The "read"
documentation is unclear and I can't figure it out.

Thanks a bunch for helping a (relative) newbie!




                                            --N.