From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8640 invoked from network); 29 Mar 1999 04:15:27 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Mar 1999 04:15:27 -0000 Received: (qmail 15944 invoked by alias); 29 Mar 1999 04:14:49 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2252 Received: (qmail 15937 invoked from network); 29 Mar 1999 04:14:48 -0000 Date: Sun, 28 Mar 1999 23:14:28 -0500 From: Sweth Chandramouli To: zsh-users@sunsite.auc.dk Subject: Re: zsh startup files Message-ID: <19990328231428.A11812@astaroth.nit.gwu.edu> Mail-Followup-To: zsh-users@sunsite.auc.dk References: <9903251002.AA18225@ibmth.df.unipi.it> <199903251055.LAA02436@sally.ifm.uni-kiel.de> <9903251117.AA09841@rouble.olsen.ch> <9903251122.AA14741@ibmth.df.unipi.it> <5l1zidiw46.fsf@tequila.cs.yale.edu> <9903251400.AA54287@ibmth.df.unipi.it> <5lyaklgy2w.fsf@tequila.cs.yale.edu> <990327170423.ZM3271@candle.brasslantern.com> <5logldgt3m.fsf@tequila.cs.yale.edu> <990328175751.ZM8402@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <990328175751.ZM8402@candle.brasslantern.com> 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 / (202) 994 - 8521 (V) / (202) 994 - 0458 (F) *