Re: Bug with _parameters and zmodload

Re: Bug with _parameters and zmodload

[Sven Wischnowsky]

Peter Stephenson wrote:

> Oliver Kiddle wrote:
> > When I upgraded to 3.1.6-pws-2 (from 3.1.6-test-2 - I've been busy recently s
> > o haven't upgraded for a while), I got a number of error messages of the foll
> > owing form:
> > 
> > _parameters: mapfile: autoload failed [43]
> > 
> > I get it for each of parameters, functions, options, commands and mapfile the
> >  first time I try to expand a variable after running zsh.
> 
> This should fix this part.  The modules were trying to unset any existing
> parameters when they installed their own.  The existing parameters were the
> autoloadable ones, and it tried to autoload the parameter to unset it, which
> it was already in the middle of doing so it couldn't.  The simplest fix is
> to retrieve the existing param struct without autoloading and unset that.

This didn't work for me, I still got the error message. The changed
test in params.c fixed that.
Then I changed the parameter module to report `undefined' parameters
like `typeset' does.

> I haven't touched the completion functions.  Probably there's no harm in
> _parameters loading the parameter module to use to check the parameters,
> since if it's autoloadable that should mean it's available for use in this
> sort of context, but that's different from the real problem.

Yes. I didn't do that because we don't have a easy way to find out if
a parameter/builtin/whatever is defined to be autoloaded (and I didn't 
want to fiddle with ${$(zmodload -ap)}).

Otherwise, I'm with Oliver here -- modules shouldn't be loaded just
because someone does `$<TAB>'. The hunks in `_parameters' should make
this.

Oliver Kiddle wrote:

> Another unrelated problem I have found is that the completion matching control to complete partial directories doesn't work when variables are used:
> I'd expect:
> cd $code[ai]/R/drop.1.34<tab>
> to complete to:
> cd $code[ai]/Releases/drop.1.34.0.rel/
> but it doesn't.

The patch also contains some hunks in `_path_files' which contain my
first attempt for this. Note that partial paths are only completed
after the parameter expansion (i.e. `f/$foo/b<TAB>' doesn't work if
`f' is only a prefix).

Bye
 Sven

diff -u os/params.c Src/params.c
--- os/params.c	Thu Sep  2 09:15:59 1999
+++ Src/params.c	Thu Sep  2 10:38:30 1999
@@ -292,7 +292,7 @@
 	if (!load_module(mn))
 	    return NULL;
 	hn = gethashnode2(ht, nam);
-	if (((Param) hn) == pm) {
+	if (((Param) hn) == pm && (pm->flags & PM_AUTOLOAD)) {
 	    pm->flags &= ~PM_AUTOLOAD;
 	    zwarnnam(nam, "autoload failed", NULL, 0);
 	}
diff -u os/Modules/parameter.c Src/Modules/parameter.c
--- os/Modules/parameter.c	Thu Sep  2 10:42:03 1999
+++ Src/Modules/parameter.c	Thu Sep  2 11:23:17 1999
@@ -83,6 +83,9 @@
     int f = pm->flags;
 
     if (!(f & PM_UNSET)) {
+	if (pm->flags & PM_AUTOLOAD)
+	    return dupstring("undefined");
+
 	switch (PM_TYPE(f)) {
 	case PM_SCALAR:  val = "scalar"; break;
 	case PM_ARRAY:   val = "array"; break;
diff -u -r Completion.old/Core/_parameters Completion/Core/_parameters
--- Completion.old/Core/_parameters	Wed Sep  1 14:24:54 1999
+++ Completion/Core/_parameters	Thu Sep  2 10:58:04 1999
@@ -27,18 +27,21 @@
 
 _description expl parameter
 
-if zmodload -e parameter; then
-  setopt localoptions extendedglob
-  pars=( ${(k)parameters[(R)^*local*]} )
-else
-  pars=( ${${${(f)"$(typeset +)"}:#*local *}##* } )
-fi
-
 if [[ -n "$slash" && -o autoparamslash ]]; then
   local i dirs nodirs ret=1
 
   dirs=()
   nodirs=()
+
+  if zmodload -e parameter; then
+    setopt localoptions extendedglob
+    nodirs=( ${(k)parameters[(R)undefined]} )
+    pars=( ${(k)parameters[(R)^*(local|undefined)*]} )
+  else
+    nodirs=( ${${(M)${(f)"$(typeset +)"}:#undefined *}##* } )
+    pars=( ${${${(f)"$(typeset +)"}:#*(local|undefined) *}##* } )
+  fi
+
   for i in $pars; do
     if [[ -d "${(P)i}" ]]; then
       dirs=( $dirs $i )
@@ -57,6 +60,13 @@
 
   return ret
 else
+  if zmodload -e parameter; then
+    setopt localoptions extendedglob
+    pars=( ${(k)parameters[(R)^*local*]} )
+  else
+    pars=( ${${${(f)"$(typeset +)"}:#*local *}##* } )
+  fi
+
   if [[ "$slash" = normal ]]; then
     compadd -S "$suf" -r ' [:' "$expl[@]" "$@" - $pars
   elif [[ "$slash" = brace ]]; then
diff -u -r Completion.old/Core/_path_files Completion/Core/_path_files
--- Completion.old/Core/_path_files	Wed Sep  1 14:24:54 1999
+++ Completion/Core/_path_files	Thu Sep  2 11:11:53 1999
@@ -173,6 +173,22 @@
   orig="${orig#*/}"
   donepath=''
   prepaths=( '' )
+elif [[ "$pre" = *\$*/* ]]; then
+
+  # If there is a parameter expansion in the word from the line, we try
+  # to complete the beast by expanding the prefix and completing anything
+  # after the first slash after the parameter expansion.
+  # This fails for things like `f/$foo/b/<TAB>' where the first `f' is
+  # meant as a partial path.
+
+  linepath="${(M)pre##*\$[^/]##/}"
+  realpath=${(e)~linepath}
+  [[ "$realpath" = "$linepath" ]] && return 1
+  pre="${pre#${linepath}}"
+  i="${#linepath//[^\\/]}"
+  orig="${orig[1,(in:i:)/][1,-2]}"
+  donepath=''
+  prepaths=( '' )
 else
   # If the string does not start with a `~' we don't remove a prefix from the
   # string.

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

Why is not parameter autoloaded? RE: Bug with _parameters and zmodload

[Andrej Borsenkow]

(Of course, this particular bug needs fixing anyway)

We have more and more uses for it. And Sven intended to extend it. So, why it is
not autoloaded?

/andrej

Re: Bug with _parameters and zmodload

[Peter Stephenson]

Peter Stephenson wrote:
> Oliver Kiddle wrote:
> > I got a number of error messages of the following form:
> > 
> > _parameters: mapfile: autoload failed [43]
> > 
> > I get it for each of parameters, functions, options, commands and mapfile
> 
> This should fix this part.

Hmm, after thinking some more, maybe the following is a neater fix than
7616?  I don't see why you should have to autoload any module just to unset
a parameter that hasn't yet been loaded, which is supposed to be what the
following prevents.  The (paramtab == realparamtab) test makes sure it only
does the short cut for top level parameters, where we know what
paramtab->getnode does; I just copied it from createparam(), where I
presume it has a similar function (don't load a parameter if you're only
about to hide it).

--- Src/params.c.upm	Mon Aug 30 16:14:05 1999
+++ Src/params.c	Thu Sep  2 10:46:28 1999
@@ -1733,7 +1733,9 @@
 {
     Param pm;
 
-    if ((pm = (Param) paramtab->getnode(paramtab, s)))
+    if ((pm = (Param) (paramtab == realparamtab ?
+		       gethashnode2(paramtab, s) :
+		       paramtab->getnode(paramtab, s))))
 	unsetparam_pm(pm, 0, 1);
 }
 

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Bug with _parameters and zmodload

[Peter Stephenson]

Oliver Kiddle wrote:
> When I upgraded to 3.1.6-pws-2 (from 3.1.6-test-2 - I've been busy recently s
> o haven't upgraded for a while), I got a number of error messages of the foll
> owing form:
> 
> _parameters: mapfile: autoload failed [43]
> 
> I get it for each of parameters, functions, options, commands and mapfile the
>  first time I try to expand a variable after running zsh.

This should fix this part.  The modules were trying to unset any existing
parameters when they installed their own.  The existing parameters were the
autoloadable ones, and it tried to autoload the parameter to unset it, which
it was already in the middle of doing so it couldn't.  The simplest fix is
to retrieve the existing param struct without autoloading and unset that.

I haven't touched the completion functions.  Probably there's no harm in
_parameters loading the parameter module to use to check the parameters,
since if it's autoloadable that should mean it's available for use in this
sort of context, but that's different from the real problem.

--- Src/Modules/mapfile.c.us	Mon Jul 19 18:05:29 1999
+++ Src/Modules/mapfile.c	Wed Sep  1 17:50:22 1999
@@ -83,7 +83,8 @@
     Param pm;
     HashTable ht;
 
-    unsetparam(mapfile_nam);
+    if ((pm = (Param) gethashnode2(paramtab, mapfile_nam)))
+	unsetparam_pm(pm, 0, 1);
     mapfile_pm = NULL;
 
     if (!(pm = createparam(mapfile_nam, PM_SPECIAL|PM_REMOVABLE|PM_HASHED)))
--- Src/Modules/parameter.c.us	Wed Sep  1 17:58:34 1999
+++ Src/Modules/parameter.c	Wed Sep  1 18:03:03 1999
@@ -617,23 +617,28 @@
      * As an example for autoloaded parameters, this is probably a bad
      * example, because we the zsh core doesn't support creation of
      * special hashes, yet. */
+    Param pm;
 
-    unsetparam(PAR_NAM);
+    if ((pm = (Param) gethashnode2(paramtab, PAR_NAM)))
+	unsetparam_pm(pm, 0, 1);
     if (!(parpm = createspecialhash(PAR_NAM, getpmparameter,
 				    scanpmparameters)))
 	return 1;
     parpm->flags |= PM_READONLY;
-    unsetparam(CMD_NAM);
+    if ((pm = (Param) gethashnode2(paramtab, CMD_NAM)))
+	unsetparam_pm(pm, 0, 1);
     if (!(cmdpm = createspecialhash(CMD_NAM, getpmcommand,
 				    scanpmcommands)))
 	return 1;
     cmdpm->sets.hfn = setpmcommands;
-    unsetparam(FUN_NAM);
+    if ((pm = (Param) gethashnode2(paramtab, FUN_NAM)))
+	unsetparam_pm(pm, 0, 1);
     if (!(funpm = createspecialhash(FUN_NAM, getpmfunction,
 				    scanpmfunctions)))
 	return 1;
     funpm->sets.hfn = setpmfunctions;
-    unsetparam(OPT_NAM);
+    if ((pm = (Param) gethashnode2(paramtab, OPT_NAM)))
+	unsetparam_pm(pm, 0, 1);
     if (!(optpm = createspecialhash(OPT_NAM, getpmoption,
 				    scanpmoptions)))
 	return 1;

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Bug with _parameters and zmodload

[Oliver Kiddle]

When I upgraded to 3.1.6-pws-2 (from 3.1.6-test-2 - I've been busy recently so haven't upgraded for a while), I got a number of error messages of the following form:

_parameters: mapfile: autoload failed [43]

I get it for each of parameters, functions, options, commands and mapfile the first time I try to expand a variable after running zsh. After this it all works and the mapfile and parameter modules are loaded. The problem is a result of my having used zmodload -ap for the parameters in these modules in my .zshrc. I put it there so that the modules would be autoloaded if I tried to use them.

_parameters correctly determines that the parameters modules is not loaded (with zmodload -e) so uses typeset + to generate the list of parameters. This is fine but note that the list of parameters includes mapfile, parameters, functions etc which are all 'undefined'. Then on line 43 (as in the error message), _parameters goes on to divide the parameters into directories and not directories. When it reaches the undefined parameters (mapfile etc), it attempts to autoload the modules. This it ofcourse should not do - it should probably assume that the parameters aren't directories. I've got no idea why it prints an error message about failing to load the module, especially as it clearly does load the module.

My first thought on a fix for this was to change line 43 to something like:

if [[ ${(Pt)i} = undefined* ]] || [[ -d ${(P)i} ]]; then

(and swap the then/else parts arround) but this will return association or whatever after loading the module. The alternative is to use typeset but I haven't done a patch because there is probably a cleaner solution. A quick-fix would be to remove undefined parameters from the list of parameters as generated by typeset +.

The separate problem of the bogus autoload failed error message seems to only occur with autoloaded parameters - zftp etc (with zmodload -a zftp) has no such problems.

Another unrelated problem I have found is that the completion matching control to complete partial directories doesn't work when variables are used:
I'd expect:
cd $code[ai]/R/drop.1.34<tab>
to complete to:
cd $code[ai]/Releases/drop.1.34.0.rel/
but it doesn't.

Oliver