Amusing (?) behavior of zsh/parameter specials

Amusing (?) behavior of zsh/parameter specials

[Bart Schaefer]

This is clearly a side-effect of feature autoloading, but:

torch% typeset -m -p fun\*
typeset functrace
typeset funcsourcetrace
typeset funcstack
typeset functions
typeset funcfiletrace
torch% : $funcstack
torch% typeset -m -p fun\*
typeset functrace
typeset funcsourcetrace
typeset functions
typeset funcfiletrace
torch% () { print $functrace }
Src/zsh:21
torch% typeset -m -p fun\*    
typeset funcsourcetrace
typeset functions
typeset funcfiletrace

Note how each parameter name disappears from the typeset output after it
has been reference once.

torch% print ${(t)functrace}
array-readonly-hide-hideval-special

Probably there's nothing to be done about this, I just found it curious.
Maybe autoloaded parameters should always be hidden until they load?

Re: Amusing (?) behavior of zsh/parameter specials

[Peter Stephenson]

On Sat, 23 Jan 2016 09:07:36 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Maybe autoloaded parameters should always be hidden until they load?

That's definitely arguable, yes.  -p and its features are there as a
concession to POSIX-style order, in order to make it easy to restore
parameters the user has defined, and autoloaded parameters, whether
disappearing or not, don't fit that picture.

pws

Re: Amusing (?) behavior of zsh/parameter specials

[Bart Schaefer]

On Jan 24,  6:26pm, Peter Stephenson wrote:
} Subject: Re: Amusing (?) behavior of zsh/parameter specials
}
} On Sat, 23 Jan 2016 09:07:36 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Maybe autoloaded parameters should always be hidden until they load?
} 
} That's definitely arguable, yes.  -p and its features are there as a
} concession to POSIX-style order, in order to make it easy to restore
} parameters the user has defined, and autoloaded parameters, whether
} disappearing or not, don't fit that picture.

Two competing potential patches for this.


I lean a little bit toward this one:

diff --git a/Src/params.c b/Src/params.c
index b2e8897..a1f0292 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -5258,7 +5258,8 @@ printparamnode(HashNode hn, int printflags)
 
     if (printflags & PRINT_TYPESET) {
 	if ((p->node.flags & (PM_READONLY|PM_SPECIAL)) ==
-	    (PM_READONLY|PM_SPECIAL)) {
+	    (PM_READONLY|PM_SPECIAL) ||
+	    (p->node.flags & PM_AUTOLOAD)) {
 	    /*
 	     * It's not possible to restore the state of
 	     * these, so don't output.


But this one has its attractions as well:

diff --git a/Src/params.c b/Src/params.c
index b2e8897..0ec0042 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -5265,7 +5265,10 @@ printparamnode(HashNode hn, int printflags)
 	     */
 	    return;
 	}
-	printf("typeset ");
+	if (p->node.flags & PM_AUTOLOAD)
+	    printf("unset ");
+	else
+	    printf("typeset ");
     }
 
     /* Print the attributes of the parameter */


The main problem with the latter one is that, if the parameter really
is read-only after autoloading, "restoring" the unset will fail.  I
guess the point is to restore the parameters that ARE set, so now that
I've written this all down I lean even more to the first variant.

Re: Amusing (?) behavior of zsh/parameter specials

[Peter Stephenson]

On Mon, 25 Jan 2016 21:11:40 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> The main problem with the latter one is that, if the parameter really
> is read-only after autoloading, "restoring" the unset will fail.  I
> guess the point is to restore the parameters that ARE set, so now that
> I've written this all down I lean even more to the first variant.

Yes, that was my attitude in previous changes for typeset -p.

pws