19924 2003-04-25 07:00 0000 `/etc/zsh/zprofile' for app-shells/zsh 2008-05-07 08:37:07 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified All Linux RESOLVED FIXED P2 enhancement --- 159890 1 croooow@gmail.com usata@gentoo.org ajs@pigpond.com bssteph@incorporeal.org esigra@gmail.com gentoo@necoro.eu insanity5902@gmail.com lk@teamten.com s4t4n@gentoo.org yar_tour@yahoo.com croooow@gmail.com 2003-04-25 07:00:13 0000 I had previously submitted a file for use as `/etc/zsh/zshenv' which has gone into use. While it is functional and was certainly an improvement over the pre-existing setup, I no longer believe it was entirely the correct solution. Having consulted the Zsh documentation regarding its start up files and compared that with that of other shells, I think that `/etc/zsh/zprofile' is the proper file to be used for what is now being done in `/etc/zsh/zshenv'. Therefore, I think that `/etc/zsh/zshenv' should be removed and replaced by `/etc/zsh/zprofile'. I will be creating an attachment for use as `/etc/zsh/zprofile' croooow@gmail.com 2003-04-25 07:05:29 0000 Created an attachment (id=11119) /etc/zsh/zprofile This is very similar to my old `/etc/zsh/zshenv'. A notable tweak is removing the unnecessary `/usr/bin/whoami' command substitution and replacing it with the Zsh `USER' environment variable. This is, at least, a bit more efficient by removing the execution of an external command. gentoo@blorf.net 2003-06-19 10:04:57 0000 Yes, I agree. The zshenv file got sourced in inappropriate times (i.e. at every shell invocation). For instance, if I ran less, it invoked zsh to run lesspipe.sh, and zshenv gets sourced (which is not desired). The only sticky problem is how to handle the old zshenv file when installing the new zprofile file. I submitted a potential solution in my zsh 4.1.1 ebuild that renames the user's zshenv file to zprofile (if they don't have a zprofile file already) during the pkg_preinst step, and then our install of the zprofile file will handle any user changes during the etc-update step. See bug 23114 for my 4.1.1 ebuild. vladimir@rio.com 2003-06-28 01:11:54 0000 So long, and thanks for all the fish usata@gentoo.org 2003-07-23 10:54:18 0000 Thank you for your contribution. Both of your comments helped me a lot. /etc/zsh/zprofile is included in zsh-4.0.7.ebuild in CVS now. duvall@comfychair.org 2003-07-28 22:39:19 0000 Hm. I just found this bug, and I'm not sure that this is the right thing. I agree that zshenv isn't the right file for this, but zprofile is sourced only at the startup of a login shell. Which means that other interactive, but not login, shells won't source this file. This is different from bash, whose man page says that /etc/profile is sourced for all interactive shells or noninteractive login shells, but the same as ksh, which says its sources /etc/profile only on login. So obviously there's room for interpretation. Just something to think about. croooow@gmail.com 2003-07-29 01:08:01 0000 My understanding of what Bash's man page states is that `/etc/profile' is read by Bash only when it is a login shell (interactive and non-interactive). Quoting Bash's man page, fourth paragraph from the section "INVOCATION": "When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. ..." usata@gentoo.org 2003-07-29 05:18:47 0000 You can check the behaviour of interactive and login shell: zsh: rico% export PATH=/bin:/usr/bin rico% (zsh -c printenv | grep '^PATH') PATH=/bin:/usr/bin rico% (zsh -i -c printenv | grep '^PATH') PATH=/bin:/usr/bin rico% (zsh -l -c printenv | grep '^PATH') PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-gentoo-linux/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin rico% (zsh -l -i -c printenv | grep '^PATH') PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-gentoo-linux/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin bash: bash-2.05b$ export PATH=/bin:/usr/bin bash-2.05b$ (bash -c printenv | grep '^PATH') PATH=/bin:/usr/bin bash-2.05b$ (bash -i -c printenv | grep '^PATH') PATH=/bin:/usr/bin bash-2.05b$ (bash -l -c printenv | grep '^PATH') PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-gentoo-linux/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin bash-2.05b$ (bash -l -i -c printenv | grep '^PATH') PATH=/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/i686-gentoo-linux/gcc-bin/3.2:/opt/Acrobat5:/usr/X11R6/bin:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/qt/2/bin From the manpage as James suggested, I think this is the right behaviour and not a bug. seemant@gentoo.org 2003-09-06 04:07:25 0000 reopen requested ajs@pigpond.com 2003-09-06 04:18:37 0000 The problem with this solution is that it may stomp over a user's .zshenv file if that's where they modify their own private PATH. The same goes for anything in set by /etc/profile.env which the user tries to set. AFAIK all environment settings should go in /etc/zsh/zshenv. This always gets sourced, sure, but it's possible to detect if you're a login and/or interactive shell and skip most of the parsing if that's the case. The INTERACTIVE and LOGIN options are the appopriate things to test for, I hope. If I get a chance later this weekend I'll try to come up with a suitable set of replacement /etc/zsh/* files. Cheers, - Andrew usata@gentoo.org 2003-09-06 09:17:37 0000 Created an attachment (id=17161) zshenv usata@gentoo.org 2003-09-06 09:32:28 0000 Hi. I was asked about the same issue two or three weeks ago at local forum but he didn't reopen this bug .... I understand it is a bit annoying if you use ~/.zshenv to set PATH enviroment. I attached a zshenv file to parse /etc/profile.env if [[ ${SHLVL} = 1 ]]. It may be [[ -o LOGIN ]] (if you prefer zsh options). Which do you think is better? ajs@pigpond.com 2003-09-06 11:16:43 0000 Personally, as a matter of style I think [[ -o LOGIN ]] is preferable since it's obvious what it's doing; the SHLVL==1 thing may be functionally equivalent but it's less clear what it's doing at a glance. Thanks for the prompt response, - Andrew gentoo@blorf.net 2003-09-06 11:53:13 0000 The problem here is that there is confusion about what .zshenv should be used for. The statment that all environment variables should go into a zshenv file (either personal or system) is incorrect. The *env files are simply sourced for all invocations of the shell, and should only be used to make modifications that need to affect every shell invocation. Many people think that they need to set their PATH in the .zshenv file, and then they get royally screwed if they do something like this: PATH=/testing/path:/usr/bin gdb test-program This completely ignores the custom PATH if their .zshenv file sets the PATH (this is because gdb runs the program using $SHELL). So, for most people, they need to move things out of their .zshenv file into their .zprofile file. In certain older X Windows environments, the .zprofile file did not get sourced, but that can be checked for and sourced in the users .zshrc file (or they can upgrade their X Windows version). ajs@pigpond.com 2003-09-06 23:56:21 0000 Wayne: Your example seems fair enough, and I admit I'd never thought of that (or been royally screwed in the manner you suggest). I was also under the impression that all environment settings go in *env, possibly due to its name. Speaking to a few friends who use zsh, it appears to be a fairly common perception. Reading the man page actually doesn't offer advice of what goes where; it only describes the behaviour. The FAQ question "3.2: In which startup file do I put...?" (<http://zsh.sunsite.dk/FAQ/zshfaq03.html#l18>) offers a bit more guidance, and indeed does advise that *login and *shrc are "are a good place to set environment variables (i.e. export commands), since they are passed on to all shells without you having to set them again". So I guess the initial closure for this bug was indeed correct and I should fix my personal startup files. :) - Andrew cselkirk@xs4all.nl 2003-09-10 10:25:43 0000 quote=Wayne Davison: "The problem here is that there is confusion about what .zshenv should be used for .." /etc/zsh/zshenv *is* the place for $path and .zshenv *should* be considerd the place to change this env. Look at StartupFiles/zshenv and you will see that this is what zshenv is intended for, and .zshenv should be respected as "the place" for a user to change this. Go to zsh.org and look at the .zshenv under startup files and you will see that $path is defined here .. it's standard and accepted practice. In my own case $path is pretty much all I define in .zshenv, and it's a fairly sure bet I will want this defined for each and every invocation .. as of the 4.0.7 update I *can't* define it here as it gets redefined in /etc/zsh/zprofile. " .. for most people, they need to move things out of their .zshenv file into their .zprofile file" No .. the package maintainer should follow the practices layed out by the zsh developers and have $path in /etc/zsh/zshenv. Additionally /etc/profile.env should not be sourced but env-update should be addapted to also support zsh. "PATH=/testing/path:/usr/bin gdb test-program" How may people do you think would really do this???!! As for defining $path it can be done in a simple array: # .zshenv # PATH typeset -U path export path path=($path ~/bin /path/bin) gentoo@blorf.net 2003-09-10 11:34:44 0000 "Look at StartupFiles/zshenv ..." Yes, I'm about to commit a patch to zsh to fix this comment, so it won't be there to mislead people much longer (yes, I'm one of the developers working on zsh). I too used to have many of my environment variables set in the .zshenv file, and I very nearly corrupted a production system at work a few years ago because of this. So, we need to be sure that environment customizations aren't lost at every shell invocation. The gdb example was just one such command that can bite people, and simply should have made it clear that improper use of the .zshenv file can bite you unexpectedly. There are lots more potential pitfalls (basically anything that uses $SHELL). So, having the system set PATH once in /etc/zprofile is the right place for it to happen. If you want to have your .zshenv file override a setting from /etc/zprofile, you can either link your .zshenv to your .zprofile file, as Bart suggests here: http://www.zsh.org/mla/users/1997/msg00575.html Or, source it from that file (if you have other things in your .zprofile). tuxie@dekadance.se 2004-03-13 01:57:36 0000 Here is a ZSH $PROMPT which looks identical to the default Gentoo BASH-prompt, both for root and for users: PROMPT=$'%{\e[1;3%(!.1.2)m%}%n@%m %{\e[34m%}%1d %(!.#.$) %{\e[0m%}' Please include it in the default zprofile. If you want it distinguishable (is that a word?:) from BASH here is the prompt I use personally. It's almost identical to the Gentoo BASH-default but it uses ~ for $HOME and % instead of $ for users. PROMPT=$'%{\e[1;3%(!.1.2)m%}%n@%m %{\e[34m%}%1~ %# %{\e[0m%}' usata@gentoo.org 2004-03-13 02:32:07 0000 I personally do not want to enable such a prompt by default. I committed Gentoo prompt like yours yesterday, bug #43753, but only added einfo to let users do the job by themselves. I like the idea of distinguising zsh prompt from bash prompt, so I'll change $ to % and home directory to ~ in the next prerelease. If there are a number of people who want to enable it by default, I'll do so, but I'll add ``vanilla'' local IUSE flag for users who don't want it. What do you think about it? lk@teamten.com 2004-04-03 21:10:04 0000 If I add ~/bin to PATH in my .zshenv, then it's clobbered by /etc/zsh/zprofile. If I move that to my .zshrc or .zprofile, then it doesn't get sourced when I ssh into the machine to run a program, like "ssh machine program". In that case "program" isn't searched in ~/bin. If I link .zprofile to .zshenv or source .zshenv from .zprofile, then .zshenv will get sourced twice for login shells (not the end of the world, but lame). For those of you who were advocating moving PATH out of .zshenv, how do you handle the "ssh" problem? (The "ssh" problem came up because subversion in ssh mode tries to run "svnserve" and it must be in your path.) Perhaps a solution is to have /etc/zsh/zprofile save the PATH on invocation, source /etc/profile.env, then merge the two paths afterwards. usata@gentoo.org 2004-04-16 10:09:19 0000 Created an attachment (id=29430) sample zprofile to preserve users' path So probablly it's better to add a patch like this? It only preserve users' PATH (scripts in /etc/env.d set many other environment variables but you cannot stop them clearing your settings in ~/.zshenv if we stick to use /etc/zsh/zprofile). lk@teamten.com 2004-12-19 18:58:04 0000 Mamoru: Your patch works for me, but like you said it only saves PATH, not MANPATH, CLASSPATH, etc. So I'm going to keep linking $HOME/.zprofile to $HOME/.zshenv for safety, even though it's slightly wasteful. It really does seem like zsh's default behavior is wrong, and it should always source the system files first, letting the user override using local files. I suppose another option is to have /etc/profile.env check each variable before setting it. Path variables would be appended and non-path variables (e.g., LESS and CC) would be left alone if they were already set. Yuk. jakub@gentoo.org 2005-08-12 00:50:52 0000 *** Bug 102189 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-09-19 08:30:22 0000 *** Bug 148196 has been marked as a duplicate of this bug. *** insanity5902@gmail.com 2006-09-21 14:44:51 0000 This doens't really have that much in common with this bug, but apperently some dev thought it did, so I will repost what I said in the other thread. The issue with with JAVA_HOME not being set accordingly with the new java-config. The code was updated with bash profile, but not zsh, and probably other shells also, but these bug looks like it is dead, and being ignored, so nothing will porbably come of this. Anyhow, this is what I found. in /etc/profile, there this code for sh in /etc/profile.d/*.sh ; do if [ -r "$sh" ] ; then . "$sh" fi done unset sh /etc/zsh/zprofile does not have this. Thereforce my java vm was being set by the old way in env.d directory. This was preventing me from using java 1.5. I check the zprofile in the zsh files dir, and this code is not in there. I think it might need to be added, I read through the docs and didn't see anything about messing with the shell's profile.T s4t4n@gentoo.org 2007-01-16 08:20:29 0000 sys-apps/qingy is affected by this bug, too. If zsh does not have the system PATHs set in /etc/zsh/zprofile, qingy is not able to fire up X sessions because xinit can't find the X server in PATH. usata@gentoo.org 2007-04-30 16:27:39 0000 Sorry for the delay. Changed zprofile to source /etc/profile.d/*.sh as suggested in comment #24. insanity5902@gmail.com 2007-04-30 17:07:08 0000 no problem ... also note that you now have to extract the value of EDITOR in zprofile also. Here is the code I use ... stolen from /etc/profile/ # Extract the value of EDITOR [ -z "$EDITOR" ] && EDITOR="`. /etc/rc.conf 2>/dev/null; echo $EDITOR`" [ -z "$EDITOR" ] && EDITOR="/bin/nano" export EDITOR As for the profile.d/*.sh, this is now how they do it, not sure if it really matters for sh in /etc/profile.d/*.sh ; do [ -r "$sh" ] && . "$sh" done unset sh Thanks for adding this , it will make new commers to zsh life a bit easier usata@gentoo.org 2007-04-30 19:32:39 0000 Sure, it is reported on bug #165000 and fixed in CVS. Thanks anyway for the information, Ryan :-) bssteph@incorporeal.org 2007-05-07 06:07:36 0000 (In reply to comment #26) > Sorry for the delay. Changed zprofile to source /etc/profile.d/*.sh as > suggested in comment #24. > A note, this will cause a warning if the directory does not contain any .sh /etc/zsh/zprofile:34: no matches found: /etc/profile.d/*.sh I made an empty .sh (dummy.sh :) to make zsh not complain when logging in. tove@gentoo.org 2008-03-17 10:21:24 0000 *** Bug 207037 has been marked as a duplicate of this bug. *** 11119 2003-04-25 07:05 0000 /etc/zsh/zprofile zprofile text/plain W1sgLWUgIi9ldGMvcHJvZmlsZS5lbnYiIF1dICYmIHNvdXJjZSAvZXRjL3Byb2ZpbGUuZW52Cgoj MDc3IHdvdWxkIGJlIG1vcmUgc2VjdXJlLCBidXQgMDIyIGlzIGdlbmVyYWxseSBxdWl0ZSByZWFs aXN0aWMKdW1hc2sgMDIyCgppZiBbWyAiJFVTRVIiID09IHJvb3QgXV0KdGhlbgoJZXhwb3J0IFBB VEg9Ii9iaW46L3NiaW46L3Vzci9iaW46L3Vzci9zYmluOiR7Uk9PVFBBVEh9IgplbHNlCglleHBv cnQgUEFUSD0iL2JpbjovdXNyL2Jpbjoke1BBVEh9IgpmaQp1bnNldCBST09UUEFUSAoK 17161 2003-09-06 09:17 0000 zshenv zshenv text/plain IyAvZXRjL3pzaC96c2hlbnYKIyAkSGVhZGVyOiAvaG9tZS9jdnNyb290L2dlbnRvby14ODYvYXBw LXNoZWxscy96c2gvZmlsZXMvenByb2ZpbGUsdiAxLjEgMjAwMy8wNy8yMyAxNzo0ODoxOSB1c2F0 YSBFeHAgJAoKaWYgW1sgJHtTSExWTH0gPSAxIF1dIDsgdGhlbgoJW1sgLWUgIi9ldGMvcHJvZmls ZS5lbnYiIF1dICYmIHNvdXJjZSAvZXRjL3Byb2ZpbGUuZW52CgoJIzA3NyB3b3VsZCBiZSBtb3Jl IHNlY3VyZSwgYnV0IDAyMiBpcyBnZW5lcmFsbHkgcXVpdGUgcmVhbGlzdGljCgl1bWFzayAwMjIK CglpZiBbWyAiJFVTRVIiID09IHJvb3QgXV07IHRoZW4KCQlleHBvcnQgUEFUSD0iL2Jpbjovc2Jp bjovdXNyL2JpbjovdXNyL3NiaW46JHtST09UUEFUSH0iCgllbHNlCgkJZXhwb3J0IFBBVEg9Ii9i aW46L3Vzci9iaW46JHtQQVRIfSIKCWZpCgl1bnNldCBST09UUEFUSApmaQo= 29430 2004-04-16 10:09 0000 sample zprofile to preserve users' path zprofile-preserve-path.diff text/plain LS0tIC91c3IvcG9ydGFnZS9hcHAtc2hlbGxzL3pzaC9maWxlcy96cHJvZmlsZQkyMDAzLTA3LTI0 IDAyOjQ4OjE5LjAwMDAwMDAwMCArMDkwMAorKysgL2V0Yy96c2gvenByb2ZpbGUJMjAwNC0wNC0w NSAwOTo1NTo0Ni40NDEzMTk3MDQgKzA5MDAKQEAgLTEsNiArMSw3IEBACiAjIC9ldGMvenNoL3pw cm9maWxlCiAjICRIZWFkZXI6IC9ob21lL2N2c3Jvb3QvZ2VudG9vLXg4Ni9hcHAtc2hlbGxzL3pz aC9maWxlcy96cHJvZmlsZSx2IDEuMSAyMDAzLzA3LzIzIDE3OjQ4OjE5IHVzYXRhIEV4cCAkCiAK K09QQVRIPSIke1BBVEh9IgogW1sgLWUgIi9ldGMvcHJvZmlsZS5lbnYiIF1dICYmIHNvdXJjZSAv ZXRjL3Byb2ZpbGUuZW52CiAKICMwNzcgd291bGQgYmUgbW9yZSBzZWN1cmUsIGJ1dCAwMjIgaXMg Z2VuZXJhbGx5IHF1aXRlIHJlYWxpc3RpYwpAQCAtMTEsNCArMTIsNyBAQAogZWxzZQogCWV4cG9y dCBQQVRIPSIvYmluOi91c3IvYmluOiR7UEFUSH0iCiBmaQotdW5zZXQgUk9PVFBBVEgKKworUEFU SD0iJHtPUEFUSH06JHtQQVRIfSIKK3R5cGVzZXQgLVUgcGF0aAordW5zZXQgUk9PVFBBVEggT1BB VEgK