Re: zsh startup files

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

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