Bug 230201
Summary: | /etc/zshenv internal documentation error | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Allan Stokes <allan> |
Component: | zsh | Assignee: | James Antill <james.antill> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | mattdm, mcepl, mcepl, triage |
Target Milestone: | --- | Keywords: | EasyFix, Patch |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | bzcl34nup | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-05-07 01:14:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Allan Stokes
2007-02-27 14:00:38 UTC
Ugh, spoo left over from trimming my RPROMPT out of the cut and paste messed up the formatting a bit. Suggested replacement comment: (notice the word ***first***) # /etc/zshenv is sourced first on all invocations of the # shell; this cannot be overridden either by means of the -f flag to zsh # or the RCS or GLOBAL_RCS options. Advantages: 1) It's extremely useful for a newbie to know with certainty where he/she can put a setting that will be in effect for every other zsh dotfile; 2) It suggests the main places to further investigate when the subsequent startup behaviour is not desirable. Additional suggestion: # It should contain commands to set the command search path, # plus other important environment variables. could be amended to read: # It should contain commands to set the command search path, # plus other important environment variables, and to load optional # zsh modules with the command zmodload -i zsh/module_name I used zsh half crippled for years because I never got past these small "where does it really go" deterents. I did some more reading, and I discovered my suggestion of loading modules in /etc/zshenv is most likely considered daft by the keepers of the faith, but the passage also confirms the behaviour of -f From http://zsh.dotsrc.org/Guide/zshguide02.html#l6 The complication is hinted at by the `see below'. The file /etc/zshenv, as it says, is always run at the start of any zsh. However, if the option NO_RCS is set (or, equivalently, the RCS option is unset: I'll talk about options shortly, since they are important in startup files), none of the others are run. The most common way of setting this option is with a flag on the command line: if you start the shell as `zsh -f', the option becomes set, so only /etc/zshenv is run and the others are skipped. Often, scripts do this as a way of trying to get a basic shell with no frills, as I'll describe below; but if something is set in /etc/zshenv, there's no way to avoid it. This leads to the First Law of Zsh Administration: put as little as possible in the file /etc/zshenv, as every single zsh which starts up has to read it. In particular, if the script assumes that only the basic options are set and /etc/zshenv has altered them, it might well not work. So, at the absolute least, you should probably surround any option settings in /etc/zshenv with if [[ ! -o norcs ]]; then ... <commands to run if NO_RCS is not set, such as setting options> ... fi and your users will be eternally grateful. Fedora 7 test bugs should be filed against "devel", not against test1/2/3. This isn't obvious, I know. Moving this report so it isn't lost. This is a bulk message -- I apologize if this was actually meant to be targeted against a different release. If so, please fix or let me know. Thanks. Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp |