zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: PATCH: Re: Really wierd problems with autoload
Date: Thu, 30 Mar 2000 13:32:34 +0200 (MET DST)	[thread overview]
Message-ID: <200003301132.NAA30426@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Wed, 29 Mar 2000 16:33:38 +0000


Bart Schaefer wrote:

> I have a function "zman" that gets set up in my .zshrc:
> --------------------------------------------------------
> zman() {
>   local f
>   for f in ${^fpath:-/usr/local/lib/zsh/functions}/run-help
>   do
>     if [[ -f $f && -r $f ]]
>     then
>         unalias run-help
>         autoload run-help
>         HELPDIR=/usr/local/lib/zsh/help
>         FPATH=$f \run-help $1
>         return $?
>     elif [[ -f /usr/local/lib/zsh/help/$1 ]]
>     then less /usr/local/lib/zsh/help/$1
>     else man $1
>     fi
>   done
> }
> alias run-help zman
               ^^^
`alias run-help=zman', right?

> 
> This used to work, but in 3.1.6-dev-20 when I type ESC-h I get
> 
> run-help:9: run-help: function definition file not found
> 
> Now, it's not run-help line 9, it's zman line 9;

That's because we do autoloading via the execautofn() function. For
the execution code, the function currently active is the dummy
function created for autoloading the real function.

The patch below makes doshfunc() set scriptname only if called for a
real function and makes execautofn() handle the scriptname, too.

> and further by the time
> zman finishes the function run-help IS correctly loaded, it just for some
> reason won't execute.  Subsequent uses of ESC-h execute the new run-help.

And it is really weird? And a problem? With FPATH=$f you say it should 
search the directory .../run-help for a file run-help. It should be
FPATH=$f:h, I think. Or maybe everybody thinks we should also check if 
the elements of $fpath are the names of the funtions searched?

(Did it ever do that? I'm pretty sure I didn't change that.)

> ...
> 
> the (autoload -U) returns nonzero when the new shell starts up, even though
> it really is 3.1.6-dev-20, and I end up with the wrong fpath so compinit
> fails, etc.  Once I've actually got a prompt, I can run (autoload -U) with
> or without the subshell and get a zero exit status, but for some strange
> reason it fails during reading of the .zshenv when there's an FPATH in the
> environment.  And it only happens on "exec", not upon running $ZSH_NAME as
> a simple external command.

Can't help here, because neither this nor...

> I noticed this because (wierd thing #3) FPATH becomes exported when zman
> does "FPATH=$f \run-help $1" ... the old value of FPATH appears to be
> restored properly after run-help fails, but if it was not exported before,
> it is afterwards.

...this happens for me.

> This is completely mystifying ... perhaps a garbage pointer is getting put
> into the environment when FPATH is exported?  But what does that have to
> do with autoload -U failing?  Maybe the whole subshell is crashing and the
> fact that it's got an autoload command in it is a red herring?  But it
> fails completely silently and without leaving a core file or anything.

Sounds scary.

Bye
 Sven

diff -ru ../z.old/Src/exec.c Src/exec.c
--- ../z.old/Src/exec.c	Thu Mar 30 12:40:40 2000
+++ Src/exec.c	Thu Mar 30 13:21:13 2000
@@ -3167,11 +3167,16 @@
 execautofn(Estate state, int do_exec)
 {
     Shfunc shf;
+    char *oldscriptname;
 
     if (!(shf = loadautofn(state->prog->shf, 1, 0)))
 	return 1;
 
+    oldscriptname = scriptname;
+    scriptname = dupstring(state->prog->shf->nam);
     execode(shf->funcdef, 1, 0);
+    scriptname = oldscriptname;
+
     return lastval;
 }
 
@@ -3243,7 +3248,7 @@
 {
     char **tab, **x, *oargv0;
     int oldzoptind, oldlastval, oldoptcind;
-    char saveopts[OPT_SIZE], *oldscriptname, *fname = dupstring(name);
+    char saveopts[OPT_SIZE], *oldscriptname = NULL, *fname = dupstring(name);
     int obreaks;
     struct funcstack fstack;
 
@@ -3258,8 +3263,10 @@
     starttrapscope();
 
     tab = pparams;
-    oldscriptname = scriptname;
-    scriptname = dupstring(name);
+    if (!(flags & PM_UNDEFINED)) {
+	oldscriptname = scriptname;
+	scriptname = dupstring(name);
+    }
     oldzoptind = zoptind;
     zoptind = 1;
     oldoptcind = optcind;
@@ -3328,7 +3335,8 @@
     pparams = tab;
     optcind = oldoptcind;
     zoptind = oldzoptind;
-    scriptname = oldscriptname;
+    if (oldscriptname)
+	scriptname = oldscriptname;
 
     if (isset(LOCALOPTIONS)) {
 	/* restore all shell options except PRIVILEGED and RESTRICTED */

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~2000-03-30 11:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-30 11:32 Sven Wischnowsky [this message]
2000-03-30 15:32 ` Bart Schaefer
2000-03-31  7:29 Sven Wischnowsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200003301132.NAA30426@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).