* zsh startup files @ 2006-03-14 17:38 zzapper 2006-03-14 18:16 ` [zsh] " Francisco Borges 2006-03-14 19:50 ` Wayne Davison 0 siblings, 2 replies; 31+ messages in thread From: zzapper @ 2006-03-14 17:38 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [zsh] zsh startup files 2006-03-14 17:38 zsh startup files zzapper @ 2006-03-14 18:16 ` Francisco Borges 2006-03-14 19:47 ` Dan Nelson 2006-03-14 19:50 ` Wayne Davison 1 sibling, 1 reply; 31+ messages in thread From: Francisco Borges @ 2006-03-14 18:16 UTC (permalink / raw) To: zsh-users » On Tue, Mar 14, 2006 at 05:38PM +0000, zzapper wrote: > 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? There is also .zlogin and .zshrc. You should move all the "interactive" part of your .zshenv into .zshrc, i.e. anything that you won't need to run your scripts. My zshenv is mostly about setting $PATH and other non interactive env. variables. While I'm sure there is good use for dot-login files, I never discovered which would be these... Oh, yes... there is .zlogout as well, but I haven't found a good excuse to create one. Cheers, Francisco ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [zsh] zsh startup files 2006-03-14 18:16 ` [zsh] " Francisco Borges @ 2006-03-14 19:47 ` Dan Nelson 0 siblings, 0 replies; 31+ messages in thread From: Dan Nelson @ 2006-03-14 19:47 UTC (permalink / raw) To: zsh-users In the last episode (Mar 14), Francisco Borges said: > On Tue, Mar 14, 2006 at 05:38PM +0000, zzapper wrote: > > 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? > > There is also .zlogin and .zshrc. > > You should move all the "interactive" part of your .zshenv into > .zshrc, i.e. anything that you won't need to run your scripts. My > zshenv is mostly about setting $PATH and other non interactive env. > variables. I alwys put one of the following comments at the top of my startup scripts so I remember what goes where, and in what order: # .zprofile -- loaded if login shell .zshenv .zprofile .zshrc .zlogin # .zshenv -- always loaded .zshenv .zprofile .zshrc .zlogin # .zshrc -- loaded if interactive shell .zshenv .zprofile .zshrc .zlogin The comments at at the top of the example scripts also have good descriptions of what should go into what script. -- Dan Nelson dnelson@allantgroup.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 2006-03-14 17:38 zsh startup files zzapper 2006-03-14 18:16 ` [zsh] " Francisco Borges @ 2006-03-14 19:50 ` Wayne Davison 2006-03-15 2:43 ` Bart Schaefer 1 sibling, 1 reply; 31+ messages in thread From: Wayne Davison @ 2006-03-14 19:50 UTC (permalink / raw) To: zzapper; +Cc: zsh-users 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.. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 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 0 siblings, 2 replies; 31+ messages in thread From: Bart Schaefer @ 2006-03-15 2:43 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 2006-03-15 2:43 ` Bart Schaefer @ 2006-03-15 18:22 ` Phil Pennock 2006-03-16 19:29 ` Dominic Mitchell 1 sibling, 0 replies; 31+ messages in thread From: Phil Pennock @ 2006-03-15 18:22 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 2006-03-15 2:43 ` Bart Schaefer 2006-03-15 18:22 ` Phil Pennock @ 2006-03-16 19:29 ` Dominic Mitchell 1 sibling, 0 replies; 31+ messages in thread From: Dominic Mitchell @ 2006-03-16 19:29 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* zsh startup files @ 1999-03-24 22:48 Stefan Monnier 1999-03-24 23:15 ` Sweth Chandramouli 1999-03-25 9:03 ` Peter Stephenson 0 siblings, 2 replies; 31+ messages in thread From: Stefan Monnier @ 1999-03-24 22:48 UTC (permalink / raw) To: zsh-users 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" ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-24 22:48 Stefan Monnier @ 1999-03-24 23:15 ` Sweth Chandramouli 1999-03-25 0:47 ` Stefan Monnier 1999-03-25 2:20 ` Jason Price 1999-03-25 9:03 ` Peter Stephenson 1 sibling, 2 replies; 31+ messages in thread From: Sweth Chandramouli @ 1999-03-24 23:15 UTC (permalink / raw) To: zsh-users 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-24 23:15 ` Sweth Chandramouli @ 1999-03-25 0:47 ` Stefan Monnier 1999-03-25 5:53 ` Sweth Chandramouli 1999-03-25 2:20 ` Jason Price 1 sibling, 1 reply; 31+ messages in thread From: Stefan Monnier @ 1999-03-25 0:47 UTC (permalink / raw) To: zsh-users >>>>> "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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-25 0:47 ` Stefan Monnier @ 1999-03-25 5:53 ` Sweth Chandramouli 1999-03-25 11:17 ` Doug Morris 0 siblings, 1 reply; 31+ messages in thread From: Sweth Chandramouli @ 1999-03-25 5:53 UTC (permalink / raw) To: zsh-users 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-25 5:53 ` Sweth Chandramouli @ 1999-03-25 11:17 ` Doug Morris 0 siblings, 0 replies; 31+ messages in thread From: Doug Morris @ 1999-03-25 11:17 UTC (permalink / raw) To: monnier, zsh-users 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"); } } ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-24 23:15 ` Sweth Chandramouli 1999-03-25 0:47 ` Stefan Monnier @ 1999-03-25 2:20 ` Jason Price 1 sibling, 0 replies; 31+ messages in thread From: Jason Price @ 1999-03-25 2:20 UTC (permalink / raw) To: Sweth Chandramouli; +Cc: zsh-users >> /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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-24 22:48 Stefan Monnier 1999-03-24 23:15 ` Sweth Chandramouli @ 1999-03-25 9:03 ` Peter Stephenson [not found] ` <9903251002.AA18225@ibmth.df.unipi.it> 1 sibling, 1 reply; 31+ messages in thread From: Peter Stephenson @ 1999-03-25 9:03 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
[parent not found: <9903251002.AA18225@ibmth.df.unipi.it>]
* Re: zsh startup files @ 1999-03-25 10:55 ` Wolfgang Hukriede 1999-03-25 11:22 ` Peter Stephenson 0 siblings, 1 reply; 31+ messages in thread From: Wolfgang Hukriede @ 1999-03-25 10:55 UTC (permalink / raw) To: zsh-users 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-25 10:55 ` Wolfgang Hukriede @ 1999-03-25 11:22 ` Peter Stephenson 1999-03-25 12:36 ` Stefan Monnier 0 siblings, 1 reply; 31+ messages in thread From: Peter Stephenson @ 1999-03-25 11:22 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-25 11:22 ` Peter Stephenson @ 1999-03-25 12:36 ` Stefan Monnier 1999-03-25 14:00 ` Peter Stephenson 0 siblings, 1 reply; 31+ messages in thread From: Stefan Monnier @ 1999-03-25 12:36 UTC (permalink / raw) To: zsh-users >>>>> "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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-25 12:36 ` Stefan Monnier @ 1999-03-25 14:00 ` Peter Stephenson 1999-03-25 19:37 ` Stefan Monnier 0 siblings, 1 reply; 31+ messages in thread From: Peter Stephenson @ 1999-03-25 14:00 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-25 14:00 ` Peter Stephenson @ 1999-03-25 19:37 ` Stefan Monnier 1999-03-28 1:04 ` Bart Schaefer 0 siblings, 1 reply; 31+ messages in thread From: Stefan Monnier @ 1999-03-25 19:37 UTC (permalink / raw) To: zsh-users >>>>> "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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-25 19:37 ` Stefan Monnier @ 1999-03-28 1:04 ` Bart Schaefer 1999-03-28 22:14 ` Stefan Monnier 0 siblings, 1 reply; 31+ messages in thread From: Bart Schaefer @ 1999-03-28 1:04 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-28 1:04 ` Bart Schaefer @ 1999-03-28 22:14 ` Stefan Monnier 1999-03-29 1:57 ` Bart Schaefer 0 siblings, 1 reply; 31+ messages in thread From: Stefan Monnier @ 1999-03-28 22:14 UTC (permalink / raw) To: zsh-users >>>>> "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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-28 22:14 ` Stefan Monnier @ 1999-03-29 1:57 ` Bart Schaefer 1999-03-29 4:14 ` Sweth Chandramouli 1999-03-29 14:15 ` Stefan Monnier 0 siblings, 2 replies; 31+ messages in thread From: Bart Schaefer @ 1999-03-29 1:57 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-29 1:57 ` Bart Schaefer @ 1999-03-29 4:14 ` Sweth Chandramouli 1999-03-29 14:15 ` Stefan Monnier 1 sibling, 0 replies; 31+ messages in thread From: Sweth Chandramouli @ 1999-03-29 4:14 UTC (permalink / raw) To: zsh-users 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> ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 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 1 sibling, 1 reply; 31+ messages in thread From: Stefan Monnier @ 1999-03-29 14:15 UTC (permalink / raw) To: zsh-users > } 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: zsh startup files 1999-03-29 14:15 ` Stefan Monnier @ 1999-03-29 14:29 ` Andrej Borsenkow 1999-03-31 7:14 ` Bart Schaefer 0 siblings, 1 reply; 31+ messages in thread From: Andrej Borsenkow @ 1999-03-29 14:29 UTC (permalink / raw) To: Stefan Monnier, zsh-users > > [ 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 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 0 siblings, 2 replies; 31+ messages in thread From: Bart Schaefer @ 1999-03-31 7:14 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-03-31 7:14 ` Bart Schaefer @ 1999-03-31 7:49 ` Bart Schaefer 1999-04-02 13:12 ` Stefan Monnier 1 sibling, 0 replies; 31+ messages in thread From: Bart Schaefer @ 1999-03-31 7:49 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 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 1 sibling, 1 reply; 31+ messages in thread From: Stefan Monnier @ 1999-04-02 13:12 UTC (permalink / raw) To: zsh-users >>>>> "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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: zsh startup files 1999-04-02 13:12 ` Stefan Monnier @ 1999-04-02 17:13 ` Bart Schaefer 0 siblings, 0 replies; 31+ messages in thread From: Bart Schaefer @ 1999-04-02 17:13 UTC (permalink / raw) To: zsh-users 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Zsh startup files @ 1996-10-19 23:04 Nate Johnston 1996-10-20 11:09 ` Zefram 0 siblings, 1 reply; 31+ messages in thread From: Nate Johnston @ 1996-10-19 23:04 UTC (permalink / raw) To: ZSH Users 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Zsh startup files 1996-10-19 23:04 Zsh " Nate Johnston @ 1996-10-20 11:09 ` Zefram 0 siblings, 0 replies; 31+ messages in thread From: Zefram @ 1996-10-20 11:09 UTC (permalink / raw) To: Nate Johnston; +Cc: zsh-users >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 ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2006-03-16 19:30 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-03-14 17:38 zsh startup files zzapper 2006-03-14 18:16 ` [zsh] " Francisco Borges 2006-03-14 19:47 ` Dan Nelson 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 -- strict thread matches above, loose matches on Subject: below -- 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 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 1996-10-19 23:04 Zsh " Nate Johnston 1996-10-20 11:09 ` Zefram
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).