From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5113 invoked from network); 10 Mar 2000 12:49:19 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Mar 2000 12:49:19 -0000 Received: (qmail 12070 invoked by alias); 10 Mar 2000 12:49:10 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10057 Received: (qmail 12056 invoked from network); 10 Mar 2000 12:49:09 -0000 Date: Fri, 10 Mar 2000 13:45:50 +0100 (MET) Message-Id: <200003101245.NAA03786@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Fri, 10 Mar 2000 12:03:22 +0000 Subject: Re: Problems with the functions[] parameter (not; but other issues) 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 set +x to, say, _diff_option, then do `diff '. 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