Re: Problems with the functions[] parameter

Re: Problems with the functions[] parameter

[Sven Wischnowsky]

Bart Schaefer wrote:

> I think that wordcode storage of functions has messed up the function[]
> assoc from the parameter module.  The value of functions[something] no
> longer accurately reflects the current state of the function `something'
> and assigning to (or using vared on) functions[something] no longer
> changes the definition of `something'.

Seems to work fine for me both with read and mapped wordcode
files... could you give me an example?

Bye
 Sven


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

Re: Problems with the functions[] parameter (not; but other issues)

[Bart Schaefer]

On Mar 10, 10:49am, Sven Wischnowsky wrote:
} Subject: Re: Problems with the functions[] parameter
}
} Bart Schaefer wrote:
} 
} > I think that wordcode storage of functions has messed up the functions[]
} > assoc from the parameter module.  The value of functions[something] no
} > longer accurately reflects the current state of the function `something'
} 
} Seems to work fine for me both with read and mapped wordcode
} files... could you give me an example?

It's me being silly.  I just figured out that the function I was editing
(to change "autoload -XU" to "autoload -XUt") was being referenced inside
a $(...), so of course the autoload doesn't replace the actual definition
in the parent.

Which leads me to two observations ...

(1) autoloading the _call function (for example) is inefficient; it is
    never used except in $(...), which means it is reloaded every time.
    Would it be useful to use e.g.

    	#autoload +X

   at the top of such files?  To mean, "load this as soon as compinit
   sees it, don't wait for it to be executed via $fpath."  (But what
   would that mean for compdump?)

(2) Redirecting stderr of a function is a bit inconsistent with respect
    to xtrace.  Zsh presently works the same way bash does, which means
    the xtrace output of shell functions is *not* redirected along with
    their stderr.  This is not the same as e.g. `do'-loops and { ... }.

And (2) in turn leads me to notice a third thing:

In bash, redirecting the standard error of the `.' command redirects
the xtrace output from the commands in the sourced file.  This doesn't
presently happen in zsh, but I think the zsh behavior is more useful;
other opinions?  Is compatibility more important?  What does ksh do?

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

Re: Problems with the functions[] parameter (not; but other issues)

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 

Interestingly, I just found the same two things, when changing
_diff_options.


> Which leads me to two observations ...
> 
> (1) autoloading the _call function (for example) is inefficient; it is
>     never used except in $(...), which means it is reloaded every time.
>     Would it be useful to use e.g.
> 
>     	#autoload +X
> 
>    at the top of such files?  To mean, "load this as soon as compinit
>    sees it, don't wait for it to be executed via $fpath."  (But what
>    would that mean for compdump?)

Yes, compdump is a problem, nice as it would be. I see only two ways:
make compinit/the-dump-file record the #autoloaded functions with the
options to #autoload in some array/assoc or add a naming convention
for files that are to be loaded immediatly. The first one would
support the nice `#autoload +X' you suggest and the latter would allow 
to get `#compdef' files loaded immediately without having to add an
extra option to compdef. Dunno if that's interesting to have for
#compdef files, though.

> (2) Redirecting stderr of a function is a bit inconsistent with respect
>     to xtrace.  Zsh presently works the same way bash does, which means
>     the xtrace output of shell functions is *not* redirected along with
>     their stderr.  This is not the same as e.g. `do'-loops and { ... }.

What really irritated me here (and it still looks wrong): add

  set -x
  _call version diff -v </dev/null 2>/dev/null
  set +x

to, say, _diff_option, then do `diff <TAB>'. At least I get:

  _diff_options:8 (): _call version diff -v
  _call:3 (): local tmp
  diff - GNU diffutils version 2.7-97r1
  _diff_options:9 (): set +x

Only the `first' line of _call is shown, xtrace output stops when
zstyle is called. Or maybe my exec.c is out-of date, because:

> And (2) in turn leads me to notice a third thing:
> 
> In bash, redirecting the standard error of the `.' command redirects
> the xtrace output from the commands in the sourced file.  This doesn't
> presently happen in zsh, but I think the zsh behavior is more useful;
> other opinions?  Is compatibility more important?  What does ksh do?

if I do `. ./foo 2> bar' I get the xtrace output of the commands in
`foo' in `bar'. Same as for the ksh I have here, btw.

Bye
 Sven


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

Re: Problems with the functions[] parameter (not; but other issues)

[Bart Schaefer]

On Mar 10,  1:45pm, Sven Wischnowsky wrote:
} Subject: Re: Problems with the functions[] parameter (not; but other issue
}
} Bart Schaefer wrote:
} > (2) Redirecting stderr of a function is a bit inconsistent with respect
} >     to xtrace.  Zsh presently works the same way bash does, which means
} >     the xtrace output of shell functions is *not* redirected along with
} >     their stderr.  This is not the same as e.g. `do'-loops and { ... }.
} 
} What really irritated me here (and it still looks wrong): add
} 
}   set -x
}   _call version diff -v </dev/null 2>/dev/null
}   set +x
} 
} Only the `first' line of _call is shown, xtrace output stops when
} zstyle is called.

Yes, I saw that too.  Improper restoration of xtrerr.  Patch below.

} Or maybe my exec.c is out-of date, because:
} 
} > And (2) in turn leads me to notice a third thing:
} > 
} > In bash, redirecting the standard error of the `.' command redirects
} > the xtrace output from the commands in the sourced file.  This doesn't
} > presently happen in zsh, but I think the zsh behavior is more useful;
} > other opinions?  Is compatibility more important?  What does ksh do?
} 
} if I do `. ./foo 2> bar' I get the xtrace output of the commands in
} `foo' in `bar'. Same as for the ksh I have here, btw.

The patch below may change this -- the behavior I previously saw for `.'
was the same as what you described for `_call' -- that is, the first line
of ./foo would xtrace to the (old) stderr, and then everything else would
be redirected to `bar', because xtrerr was getting reset too soon.

The patch below leaves `.' behaving like functions do.  If we want `.'
(and `source') to act like a shell construct instead (for bash and ksh
compatibility if nothing else) then we'll have to set xtrerr back to
stderr (temporarily) in either builtin.c:bin_dot() or init.c:source().

Index: Src/exec.c
===================================================================
@@ -1608,6 +1608,7 @@
     LinkList redir;
     wordcode code;
     Wordcode beg = state->pc, varspc;
+    FILE *oxtrerr = xtrerr;
 
     doneps4 = 0;
     redir = (wc_code(*state->pc) == WC_REDIR ? ecgetredirs(state) : NULL);
@@ -2317,10 +2318,10 @@
     fixfds(save);
 
  done:
-    if (xtrerr != stderr) {
+    if (xtrerr != oxtrerr) {
 	fil = fileno(xtrerr);
 	fclose(xtrerr);
-	xtrerr = stderr;
+	xtrerr = oxtrerr;
 	zclose(fil);
     }
 }

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