Re: named directory bug

Re: named directory bug

[Peter Stephenson]

Vincent Lefevre wrote:
> On Thu, Nov 01, 2001 at 17:43:07 +0000, Bart Schaefer wrote:
> > That's odd.  What do you see if you run this function?
> >=20
> >     tryit() {
> > 	hash -d
> > 	setopt localoptions xtrace
> > 	eval "local +h nameddirs; nameddirs=3D(${(@kvq)nameddirs})"
> >     }
> 
> tmparch=3D/global/greux/lefevre/private/tmparch
> +tryit:3> eval local +h nameddirs; nameddirs=(out) local +h
> nameddirs; nameddirs=(/users/spaces/lefevre/private/out) local +h

You have RCEXPANDPARAM turned on.  Turn the setopt into
  emulate -L zsh
  setopt xtrace
and it should work as expected.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: named directory bug

[Bart Schaefer]

On Nov 2, 10:21am, Peter Stephenson wrote:
}
} You have RCEXPANDPARAM turned on.  Turn the setopt into
}   emulate -L zsh
}   setopt xtrace
} and it should work as expected.

Except of course that the command in question is supposed to go into
_main_complete, which needs RCEXPANDPARAM.

Use

    eval "local +h nameddirs; nameddirs=(${(@kvq)^^nameddirs})"

to disable RCEXPANDPARAM for that expansion only.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: named directory bug

[Vincent Lefevre]

On Fri, Nov 02, 2001 at 10:34:03 +0000, Bart Schaefer wrote:
> Use
> 
>     eval "local +h nameddirs; nameddirs=(${(@kvq)^^nameddirs})"
> 
> to disable RCEXPANDPARAM for that expansion only.

Thanks, this seems to work!

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: named directory bug

[Clint Adams]

> Except of course that the command in question is supposed to go into
> _main_complete, which needs RCEXPANDPARAM.
> 
> Use
> 
>     eval "local +h nameddirs; nameddirs=(${(@kvq)^^nameddirs})"
> 
> to disable RCEXPANDPARAM for that expansion only.

Should this go into the canonical _main_complete?

Re: named directory bug

[Bart Schaefer]

On Apr 13,  2:31pm, Clint Adams wrote:
}
} >     eval "local +h nameddirs; nameddirs=(${(@kvq)^^nameddirs})"
} > 
} > to disable RCEXPANDPARAM for that expansion only.
} 
} Should this go into the canonical _main_complete?

The bug that code was designed to address should have been fixed by the
C code patch in zsh-workers/16201.  So unless the bug wasn't actually
fixed, no, that should not go into _main_complete.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: named directory bug

[Bart Schaefer]

On Nov 1,  3:40pm, Peter Stephenson wrote:
}
} Bart Schaefer wrote:
} > I've thought using parameters for named directories was a bad idea for a
} > very long time, ever since my csh-junkie hack of `chpwd () { cwd=$PWD }'
} > started causing `~cwd' to show up in my prompt.  (Guess when autonamedirs
} > became an option rather than the default behavior.)  At the very least I
} > think there should be a parameter flag for "this parameter is a nameddir"
} > checked by unsetparam_pm() and strsetfn() before calling adduserdir().
} 
} Would it help if we avoid local variables becoming directory names, or at
} least checked if there was already a name before adding one for a local
} variable?

That might help this bug, but it'd introduce others.

At present the only connection between the paramtab and the nameddirtab is
by the name of the parameter.  If the same name exists in both places, then
changing the parameter clobbers the nameddir.

Skipping the nameddir change for local parameters would prevent the problem
with name clashes, but it would break code that actually uses local params
as nameddirs; e.g., currently something like this works:

	foo() {
	    local t=$TMPPREFIX:h
	    echo ~t
	}

However, the patches to add a PM_NAMEDDIR flag are pretty minimal; in fact,
here they are, except that I haven't modified `typeset' to be able to set
the flag explicitly (`-d' is available) -- but maybe it never needs to be
set explicitly.

Index: Src/utils.c
===================================================================
--- Src/utils.c	2001/10/22 14:36:45	1.9
+++ Src/utils.c	2001/11/01 16:04:00
@@ -571,6 +571,7 @@
     if ((pm = (Param) paramtab->getnode(paramtab, name)) &&
 	    (PM_TYPE(pm->flags) == PM_SCALAR) &&
 	    (str = getsparam(name)) && *str == '/') {
+	pm->flags |= PM_NAMEDDIR;
 	adduserdir(name, str, 0, 1);
 	return str;
     }
Index: Src/params.c
===================================================================
--- Src/params.c	2001/07/10 09:05:21	1.11
+++ Src/params.c	2001/11/01 16:02:16
@@ -2149,6 +2149,7 @@
 	paramtab->addnode(paramtab, oldpm->nam, oldpm);
 	if ((PM_TYPE(oldpm->flags) == PM_SCALAR) &&
 	    !(pm->flags & PM_HASHELEM) &&
+	    (oldpm->flags & PM_NAMEDDIR) &&
 	    oldpm->sets.cfn == strsetfn)
 	    adduserdir(oldpm->nam, oldpm->u.str, 0, 0);
 	if (oldpm->flags & PM_EXPORTED) {
@@ -2233,8 +2234,11 @@
 {
     zsfree(pm->u.str);
     pm->u.str = x;
-    if (!(pm->flags & PM_HASHELEM))
+    if (!(pm->flags & PM_HASHELEM) &&
+	((pm->flags & PM_NAMEDDIR) || isset(AUTONAMEDIRS))) {
+	pm->flags |= PM_NAMEDDIR;
 	adduserdir(pm->nam, x, 0, 0);
+    }
 }
 
 /* Function to get value of an array parameter */

Index: Src/zsh.h
===================================================================
--- Src/zsh.h	2001/10/17 14:38:29	1.8
+++ Src/zsh.h	2001/11/01 15:46:08
@@ -1134,6 +1134,7 @@
 #define PM_AUTOLOAD	(1<<23) /* autoloaded from module                   */
 #define PM_NORESTORE	(1<<24)	/* do not restore value of local special    */
 #define PM_HASHELEM     (1<<25) /* is a hash-element */
+#define PM_NAMEDDIR     (1<<26) /* has a corresponding nameddirtab entry    */
 
 /* The option string corresponds to the first of the variables above */
 #define TYPESET_OPTSTR "aiEFALRZlurtxUhHT"

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: named directory bug

[Peter Stephenson]

Bart Schaefer wrote:
> I've thought using parameters for named directories was a bad idea for a
> very long time, ever since my csh-junkie hack of `chpwd () { cwd=$PWD }'
> started causing `~cwd' to show up in my prompt.  (Guess when autonamedirs
> became an option rather than the default behavior.)  At the very least I
> think there should be a parameter flag for "this parameter is a nameddir"
> checked by unsetparam_pm() and strsetfn() before calling adduserdir().

Would it help if we avoid local variables becoming directory names, or at
least checked if there was already a name before adding one for a local
variable?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************