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