Bug 230201 - /etc/zshenv internal documentation error
/etc/zshenv internal documentation error
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: zsh (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: James Antill
bzcl34nup
: EasyFix, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-27 09:00 EST by Allan Stokes
Modified: 2008-05-06 21:14 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 21:14:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Allan Stokes 2007-02-27 09:00:38 EST
Description of problem:

Internal to /etc/zshenv this comment text is present:  

# /etc/zshenv is sourced on all invocations of the
# shell, unless the -f option is set.  

man zshall, in section STARTUP/SHUTDOWN FILES, states:  

Commands  are  first read from /etc/zshenv; this cannot be overridden.  

I conducted my own test by adding these lines to /etc/zshenv:  

zmodload -i zsh/datetime 
export ETC_ZSHENV=$EPOCHSECONDS

Typing rather slowly, I observe this output:  

krumm% zsh                                                                     
                                     
krumm% echo $ETC_ZSHENV 
                                                                               
            1172584508
krumm% zsh -f                                                                  
                                     
krumm% echo $ETC_ZSHENV    
1172584520

Version-Release number of selected component (if applicable):

Linux krumm 2.6.19-1.2895.fc6 #1 SMP Wed Jan 10 18:50:56 EST 2007 x86_64 x86_64
x86_64 GNU/Linux
zsh 4.2.6 (x86_64-redhat-linux-gnu)

How reproducible:

If my install is typical, it's a permanent condition.    

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Allan Stokes 2007-02-27 09:20:05 EST
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.  
Comment 2 Allan Stokes 2007-02-27 11:14:55 EST
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. 
Comment 3 Matthew Miller 2007-04-10 12:36:00 EDT
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.
Comment 4 Bug Zapper 2008-04-03 15:16:47 EDT
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.
Comment 5 Bug Zapper 2008-05-06 21:14:22 EDT
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

Note You need to log in before you can comment on or make changes to this bug.