zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH: Re: Really wierd problems with autoload
@ 2000-03-31  7:29 Sven Wischnowsky
  0 siblings, 0 replies; 3+ messages in thread
From: Sven Wischnowsky @ 2000-03-31  7:29 UTC (permalink / raw)
  To: zsh-workers


I wrote:

> Bart Schaefer wrote:
> 
> ...
>
> > 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.

Grrrr, this didn't work for parse errors, of course.

Bye
 Sven

diff -ru ../z.old/Src/exec.c Src/exec.c
--- ../z.old/Src/exec.c	Fri Mar 31 09:18:49 2000
+++ Src/exec.c	Fri Mar 31 09:25:12 2000
@@ -3420,11 +3420,15 @@
 		d = (char *) zalloc(len + 1);
 		lseek(fd, 0, 0);
 		if (read(fd, d, len) == len) {
+		    char *oldscriptname = scriptname;
+
 		    close(fd);
 		    d[len] = '\0';
 		    d = metafy(d, len, META_REALLOC);
 
+		    scriptname = dupstring(s);
 		    r = parse_string(d, 1);
+		    scriptname = oldscriptname;
 
 		    zfree(d, len + 1);
 

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PATCH: Re: Really wierd problems with autoload
  2000-03-30 11:32 Sven Wischnowsky
@ 2000-03-30 15:32 ` Bart Schaefer
  0 siblings, 0 replies; 3+ messages in thread
From: Bart Schaefer @ 2000-03-30 15:32 UTC (permalink / raw)
  To: zsh-workers

On Mar 30,  1:32pm, Sven Wischnowsky wrote:
} Subject: PATCH: Re: Really wierd problems with autoload
}
} Bart Schaefer wrote:
} 
} > alias run-help zman
}                ^^^
} `alias run-help=zman', right?

You're talkng to the original CSH_JUNKIE, Sven.  I have a shell function
named `alias' that pastes in the `=' for me and then calls the builtin.  I
often forget about that when cutting snippets for posting.
 
} > run-help:9: run-help: function definition file not found
} > 
} > 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

D'oh!  How silly ... but that still doesn't explain how the function got
loaded in the first place!  Because it *is* loaded by the end of zman,
it just didn't *execute* during zman.  If it were just not loaded at all,
I'd be less mystified.

} 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?

No, no, it was just me making a typo when updating the function from its
form for a previous version of zsh.  That's why "it always worked before."

But fixing $f:h doesn't have any effect on the rest of the wierd exported
FPATH behavior that I described.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


^ permalink raw reply	[flat|nested] 3+ messages in thread

* PATCH: Re: Really wierd problems with autoload
@ 2000-03-30 11:32 Sven Wischnowsky
  2000-03-30 15:32 ` Bart Schaefer
  0 siblings, 1 reply; 3+ messages in thread
From: Sven Wischnowsky @ 2000-03-30 11:32 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2000-03-31  7:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-31  7:29 PATCH: Re: Really wierd problems with autoload Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
2000-03-30 11:32 Sven Wischnowsky
2000-03-30 15:32 ` Bart Schaefer

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).