loading user startup files for zsh scripts

loading user startup files for zsh scripts

[Greg Klanderman]

As far as I can tell other shells inhibit loading user startup files
when invoked as a shell script (i.e. #!/bin/zsh).  Should '-f' be the
default for this use case?

thanks,
Greg

Re: loading user startup files for zsh scripts

[Bart Schaefer]

On Feb 7,  3:34pm, Greg Klanderman wrote:
} 
} As far as I can tell other shells inhibit loading user startup files
} when invoked as a shell script (i.e. #!/bin/zsh).  Should '-f' be the
} default for this use case?

In a word, no.

Zsh already "inhibits" /etc/zprofile and ~/.zprofile when the shell is
not a login shell, and further skips /etc/zshrc and ~/.zshrc when the
shell is not interactive.  The only file for which -f matters during
script startup is ~/.zshenv.

The whole reason that ~/.zshenv exists is to contain commands that are
intended to be sourced by *every* zsh including scripts.  This was a
deliberate design decision; if you don't want any such initialization
done, you can remove that file.

Incidentally, documentation oddness [this has probably been mentioned
before]:  If zsh is configured with --disable-zshenv, then references
to /etc/zshenv in the documentation are replaced with the word "no",
which leads to phrases like "Commands are first read from no; this
cannot be overridden" and "As no is run for all instances of zsh, it
is important that it be kept as small as possible."

Re: loading user startup files for zsh scripts

[Greg Klanderman]

>>>>> On February 8, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> The whole reason that ~/.zshenv exists is to contain commands that are
> intended to be sourced by *every* zsh including scripts.  This was a
> deliberate design decision; if you don't want any such initialization
> done, you can remove that file.

The problem is that I create plenty of non-login & non-interactive
shells in which I want to use my aliases and functions (for example
those created by running commands from emacs) but those aliases and
functions really shouldn't be seen by scripts my team creates at work.
We can use '-f' in those scripts, but it is often overlooked, even by
me, who knows better.  I would much rather have to opt in to this
behavior.  Would it make sense to have another file sourced for all
shells that are not running scripts?

What's the best way to determine that the shell is running a script?

Greg

Re: loading user startup files for zsh scripts

[Peter Stephenson]

On Tue, 8 Feb 2011 12:09:41 -0500
Greg Klanderman <gak@klanderman.net> wrote:
> What's the best way to determine that the shell is running a script?

You can test if [[ $0 == zsh ]].  If it is, either you're running a
script helpfully called zsh, or you're not running a script at all.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: loading user startup files for zsh scripts

[Greg Klanderman]

>>>>> On February 8, 2011 Peter Stephenson <Peter.Stephenson@csr.com> wrote:

> You can test if [[ $0 == zsh ]].  If it is, either you're running a
> script helpfully called zsh, or you're not running a script at all.

/bin/zsh -c 'echo $0'

prints '/bin/zsh' so that's not exactly right I guess.  Isn't there
some case where it can end up '-zsh' as well?

thanks,
Greg

Re: loading user startup files for zsh scripts

[Bart Schaefer]

On Feb 8,  7:37pm, Greg Klanderman wrote:
} Subject: Re: loading user startup files for zsh scripts
}
} 
} >>>>> On February 8, 2011 Peter Stephenson <Peter.Stephenson@csr.com> wrote:
} 
} > You can test if [[ $0 == zsh ]].  If it is, either you're running a
} > script helpfully called zsh, or you're not running a script at all.
} 
} /bin/zsh -c 'echo $0'
} 
} prints '/bin/zsh' so that's not exactly right I guess.

I was going to suggest testing $0 also, though slightly differently.

    if [[ $ZSH_NAME == (|-)$0:t ]]
    then print This shell is unlikely to be reading a script
    else print This shell is almost certainly reading a script
    fi

The ZSH_NAME variable is always constructed from the tail of the path
name of the command interpreter, so if $0 is the same then you are not
running a script -- or the script has the same basename as the shell,
but then you're into the realm of deliberate tomfoolery.

} Isn't there some case where it can end up '-zsh' as well?

That normally happens only for login shells started by terminal manager
processes like getty (mingetty, etc.).  It can be deliberately be made
to happen by using zsh's ARGV0 environment variable, or by an executable
poking something into the arguments of execve() et al.

For your purposes, if a script were deliberately run as a login shell
(e.g., with "#!/bin/zsh -l"), wouldn't you want it to read ~/.zshenv?
In which case you can discard the (|-) that I threw in to that test.

Re: loading user startup files for zsh scripts

[Greg Klanderman]

Thanks Bart!

Re: loading user startup files for zsh scripts

[Greg Klanderman]

>>>>> On February 8, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> The ZSH_NAME variable is always constructed from the tail of the path
> name of the command interpreter, so if $0 is the same then you are not

Is there any way to get the original $0 from within a file that's
being source'd from .zshenv and when functionargzero hasn't been
unsetopt'd?  I've got a lot of people sharing a common set of startup
files by having .zshenv simply source the shared top-level file.  Much
easier to modify the source'd file than getting people to change their
.zshenv.

Greg

Re: loading user startup files for zsh scripts

[Bart Schaefer]

On Feb 9, 11:01am, Greg Klanderman wrote:
}
} Is there any way to get the original $0 from within a file that's
} being source'd from .zshenv and when functionargzero hasn't been
} unsetopt'd?

Put something in /etc/zshenv (or whatever path has been compiled for
that on your system) that stashes $0 in another parameter.  (This is
one of the few good uses of /etc/zshenv that I've ever considered; I
usually configure --disable-zshenv when building the shell myself.)

Or just do the $ZSH_NAME = $0:t test in /etc/zshenv and set a boolean
to indicate a script is running.

Re: loading user startup files for zsh scripts

[Greg Klanderman]

>>>>> On February 9, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> Put something in /etc/zshenv (or whatever path has been compiled for
> that on your system) that stashes $0 in another parameter.

Unfortunately I cannot modify /etc/zshenv on the one to two hundred
people's machines that are using our shared zsh startup files at work;
I can suggest they modify ~/.zshenv but it's unlikely to be widely
followed, which is why I was looking for a solution in the shared file
sourced by ~/.zshenv, but it sounds like that just can't work.

thanks,
Greg

Re: loading user startup files for zsh scripts

[Bart Schaefer]

On Feb 10, 11:30am, Greg Klanderman wrote:
}
} Unfortunately I cannot modify /etc/zshenv on the one to two hundred
} people's machines that are using our shared zsh startup files at work;
} I can suggest they modify ~/.zshenv but it's unlikely to be widely
} followed, which is why I was looking for a solution in the shared file
} sourced by ~/.zshenv, but it sounds like that just can't work.

Hmm.  Yeah, I tried examining things like $funcfiletrace etc. and they
don't provide any additional information.

I can suggest a draconian solution: make update more than a suggestion.

Change your shared file to have it require that $0 be passed as an
argument, e.g.

	source /the/shared/zshenv $0

This shows up as $1 in your shared file.  Have the file do NOTHING if
there is no $1, otherwise test $1 against $ZSH_NAME, etc.  Maybe if
the shell is interactive, print a warning.

That way your users are forced to update their ~/.zshenv if they want
to continue getting the benefit of your shared file.

If you want to be even MORE draconian, give them a week and then have
the file call exit if there is no $0, so their shells just plain die
until they fix it.  (Exclude login shells from that approach ...)

-- 

Re: loading user startup files for zsh scripts

[Greg Klanderman]

>>>>> On February 10, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> Hmm.  Yeah, I tried examining things like $funcfiletrace etc. and they
> don't provide any additional information.

Thanks for really digging Bart!

> I can suggest a draconian solution: make update more than a suggestion.

Sadly, draconian solutions are just not acceptable short of needing to
patch a security vulnerability.  :-)

> Change your shared file to have it require that $0 be passed as an
> argument, e.g.

> 	source /the/shared/zshenv $0

> This shows up as $1 in your shared file.  Have the file do NOTHING if
> there is no $1, otherwise test $1 against $ZSH_NAME, etc.  Maybe if
> the shell is interactive, print a warning.

Now that's actually got me thinking of a less draconian variant which
I like; if $0 is passed in (as $1) then I can DTRT, otherwise (if they
have not updated ~/.zshenv), if not a login or interactive shell then
do nothing.  They only lose the benefit of the shared file in the case
that's ambiguous and which also happens to be the case which probably
almost nobody is actually taking advantage of.

On a related note, would you be opposed to adding some way to find out
definitively whether you're running as a script from within zsh?
Would adding a new parameter be best?  Can you suggest a name?  Is
runscript != NULL in zsh_main() the right condition to use?  Or maybe
just set some parameter to the value of runscript when set?

thanks!
Greg

Re: loading user startup files for zsh scripts

[Greg Klanderman]

>>>>> On February 10, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> Change your shared file to have it require that $0 be passed as an
> argument, e.g.
>
> 	source /the/shared/zshenv $0

Hmmm, AFAICT, when loading .zshenv, $0 is /bin/zsh even for shell
scripts.  It does contain the script path once in the script.

Greg

Re: loading user startup files for zsh scripts

[Bart Schaefer]

On Feb 10,  8:42pm, Greg Klanderman wrote:
}
} > 	source /the/shared/zshenv $0
} 
} Hmmm, AFAICT, when loading .zshenv, $0 is /bin/zsh even for shell
} scripts.  It does contain the script path once in the script.

Well, that certainly takes me by surprise, because I was sure I'd
tried that ... but indeed looking through init.c the script name of
$0 isn't set up until after ALL the init files have been read.  

This is odd considering that $* has already been set to the script
arguments by the time .zshenv is processed.  It also means that zsh
will read all the init files before discovering that it can't read
the script file.

I'm also finding it a little weird that $0 apparently might be a
metafied string, since setupshin() believes that unmeta(runscript)
is necessary before calling e.g. access().  As far as I can tell
the value would never be unmetafied before being returned via $0,
so that would imply there are circumstances in which $0 is broken.
I don't know what they'd be.

Earlier:

} On a related note, would you be opposed to adding some way to find out
} definitively whether you're running as a script from within zsh?
} Would adding a new parameter be best?  Can you suggest a name?  Is
} runscript != NULL in zsh_main() the right condition to use?  Or maybe
} just set some parameter to the value of runscript when set?

I'm inclined to suggest ZSH_SCRIPT to be initialized from runscript.
I'd also like to get ZSH_INTERPRETER to be the actual path to the shell
executable, but I suspect that's not universally available from the OS.

Returning to your original problem ... I don't suppose all these user's
hosts are running linux?  You can examine /proc/$$/cmdline to find out
if a script name appears.

Re: loading user startup files for zsh scripts

[Greg Klanderman]

>>>>> On February 10, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> This is odd considering that $* has already been set to the script
> arguments by the time .zshenv is processed.  It also means that zsh
> will read all the init files before discovering that it can't read
> the script file.

This appears to be due to support for the (undocumented) PATHSCRIPT
option, whereby the path is searched for the runscript, and therefore
the startup files must be read first so that PATH can be set properly.

> I'm also finding it a little weird that $0 apparently might be a
> metafied string, since setupshin() believes that unmeta(runscript)
> is necessary before calling e.g. access().

Did you note this line near the top of zsh_main():

|    for (t = argv; *t; *t = metafy(*t, -1, META_ALLOC), t++);

i.e. all the argv arguments are metified early on.

> I'm inclined to suggest ZSH_SCRIPT to be initialized from runscript.

How is the patch below?  I can add doc if you like it.. one open
question is whether you want $ZSH_SCRIPT to be unset or empty when not
running a script; currently it would be empty, which might be useful
for detecting whether zsh is providing that parameter.

> I'd also like to get ZSH_INTERPRETER to be the actual path to the shell
> executable, but I suspect that's not universally available from the OS.

Didn't touch this one.

> Returning to your original problem ... I don't suppose all these user's
> hosts are running linux?  You can examine /proc/$$/cmdline to find out
> if a script name appears.

Oooh that's tricky, yes all are a variety of linux distros, mostly
debian/ubuntu and FC/RHEL/Centos.  Still would have to parse it and
deal with the nul byte separators, yuck.

Greg


Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.118
diff -u -r1.118 init.c
--- Src/init.c	11 Feb 2011 04:04:05 -0000	1.118
+++ Src/init.c	11 Feb 2011 16:22:50 -0000
@@ -1485,6 +1485,7 @@
     opts[USEZLE] = 1;   /* may be unset in init_io() */
     /* sets INTERACTIVE, SHINSTDIN and SINGLECOMMAND */
     parseargs(argv, &runscript);
+    zsh_script = runscript;
 
     SHTTY = -1;
     init_io();
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.169
diff -u -r1.169 params.c
--- Src/params.c	16 Jan 2011 20:35:31 -0000	1.169
+++ Src/params.c	11 Feb 2011 16:22:51 -0000
@@ -80,7 +80,8 @@
      *rprompt2,		/* $RPROMPT2    */
      *sprompt,		/* $SPROMPT     */
      *wordchars,	/* $WORDCHARS   */
-     *zsh_name;		/* $ZSH_NAME    */
+     *zsh_name,		/* $ZSH_NAME    */
+     *zsh_script;	/* $ZSH_SCRIPT  */
 /**/
 mod_export
 char *ifs,		/* $IFS         */
@@ -779,6 +780,7 @@
     setsparam("TTY", ztrdup(ttystrname));
     setsparam("VENDOR", ztrdup(VENDOR));
     setsparam("ZSH_NAME", ztrdup(zsh_name));
+    setsparam("ZSH_SCRIPT", ztrdup(zsh_script));
     setsparam("ZSH_VERSION", ztrdup(ZSH_VERSION));
     setsparam("ZSH_PATCHLEVEL", ztrdup(ZSH_PATCHLEVEL));
     setaparam("signals", sigptr = zalloc((SIGCOUNT+4) * sizeof(char *)));

Re: loading user startup files for zsh scripts

[Bart Schaefer]

On Feb 11, 11:28am, Greg Klanderman wrote:
}
} >>>>> On February 10, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:
} > I'm also finding it a little weird that $0 apparently might be a
} > metafied string, since setupshin() believes that unmeta(runscript)
} > is necessary before calling e.g. access().
} 
} Did you note this line near the top of zsh_main():
} 
} |    for (t = argv; *t; *t = metafy(*t, -1, META_ALLOC), t++);
} 
} i.e. all the argv arguments are metified early on.

Indeed.  Still, I must be missing where the un-metafication happens in
parameter substitution.

} > I'm inclined to suggest ZSH_SCRIPT to be initialized from runscript.
} 
} How is the patch below?

Looks basically as I was expecting, though it brings up another question:
Why have zsh_name et al. hanging around permanently as globals when the
strings get ztrdup()'d to set the parameters?  There are some cases
where the global gets used more than once, but zsh_name (and after this
patch zsh_script, among others) are only used in createparamtable(),
which is called exactly once.

I suppose it's easier than trying to pass them back and forth through
all the functions that perform shell initialization via zsh_main().

} I can add doc if you like it.. one open
} question is whether you want $ZSH_SCRIPT to be unset or empty when not
} running a script; currently it would be empty, which might be useful
} for detecting whether zsh is providing that parameter.

I think empty is OK, but let's hear from PWS.

} > Returning to your original problem ... I don't suppose all these user's
} > hosts are running linux?  You can examine /proc/$$/cmdline to find out
} > if a script name appears.
} 
} Oooh that's tricky, yes all are a variety of linux distros, mostly
} debian/ubuntu and FC/RHEL/Centos.  Still would have to parse it and
} deal with the nul byte separators, yuck.

Nul byte separators are no problem, zsh's IFS has nul in it by default.

    print -l -- $(</proc/$$/cmdline)

But it's true you would then have to skip over shell options to find
the script name.  I don't suppose anyone out there has written a
zparseopts spec that matches the zsh invocation-time option set?

Re: loading user startup files for zsh scripts

[Peter Stephenson]

On Fri, 11 Feb 2011 09:26:02 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } I can add doc if you like it.. one open
> } question is whether you want $ZSH_SCRIPT to be unset or empty when
> not } running a script; currently it would be empty, which might be
> useful } for detecting whether zsh is providing that parameter.
> 
> I think empty is OK, but let's hear from PWS.

I think empty is much more Zen-like, so fits perfectly.

More(?) seriously, I don't think we'd want [[ -z $ZSH_SCRIPT ]] to
trigger a "NO_UNSET" error if you weren't running a script, and I don't
think (( ${+ZSH_SCRIPT} )) is as common an idiom for special variables.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: loading user startup files for zsh scripts

[Bart Schaefer]

On Feb 11,  9:26am, Bart Schaefer wrote:
}
}     print -l -- $(</proc/$$/cmdline)
} 
} But it's true you would then have to skip over shell options to find
} the script name.  I don't suppose anyone out there has written a
} zparseopts spec that matches the zsh invocation-time option set?

Hmm, you really don't need to parse from the left, now that I think on it.

IFS=$'\0' cmdline=( $(</proc/$$/cmdline) )
(( scriptword = $#cmdline - ARGC - 1 ))
if [[ scriptword -gt 1 &&
      opt$cmdline[scriptword-1] != opt-c &&
      -r $cmdline[scriptword] ]]
then print This shell seems to be running script $cmdline[scriptword]
else print This shell does not seem to be running a script
fi

Re: loading user startup files for zsh scripts

[Peter Stephenson]

On Fri, 11 Feb 2011 11:28:43 -0500
Greg Klanderman <gak@klanderman.net> wrote:
> This appears to be due to support for the (undocumented) PATHSCRIPT
> option, whereby the path is searched for the runscript, and therefore
> the startup files must be read first so that PATH can be set properly.

It's not undocumented.

pindex(PATH_SCRIPT)
pindex(NO_PATH_SCRIPT)
pindex(PATHSCRIPT)
pindex(NOPATHSCRIPT)
cindex(path search, for script argument to shell)
item(tt(PATH_SCRIPT) <K> <S>)(
If this option is not set, a script passed as the first non-option argument
to the shell must contain the name of the file to open.  If this
option is set, and the script does not specify a directory path,
the script is looked for first in the current directory, then in the
command path.  See
ifnzman(noderef(Invocation))\
ifzman(the section INVOCATION in zmanref(zsh)).
)

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/