Partial implementation of "nameref", sort of.

Partial implementation of "nameref", sort of.

[Bart Schaefer]

This is incomplete, but presented for consideration of how to proceed
with it.

There are obviously some additional checks that could be made, e.g.,
be sure that a PM_FAKENAMEREF is also a PM_SCALAR and is not a numeric
subtype, etc.

With this patch:

% typeset -n foo=bar
% bar=hello
% echo $foo
hello

However, it doesn't work for ${foo} because the itype_end() test in
paramsubst() doesn't account for the braces.


diff --git a/Src/builtin.c b/Src/builtin.c
index 08be1ac..8d8b125 100644
--- a/Src/builtin.c
+++ b/Src/builtin.c
@@ -120,7 +120,7 @@ static struct builtin builtins[] =
     BUILTIN("trap", BINF_PSPECIAL | BINF_HANDLES_OPTS, bin_trap, 0, -1, 0, NULL, NULL),
     BUILTIN("true", 0, bin_true, 0, -1, 0, NULL, NULL),
     BUILTIN("type", 0, bin_whence, 0, -1, 0, "ampfsSw", "v"),
-    BUILTIN("typeset", BINF_PLUSOPTS | BINF_MAGICEQUALS | BINF_PSPECIAL, bin_typeset, 0, -1, 0, "AE:%F:%HL:%R:%TUZ:%afghi:%klprtuxmz", NULL),
+    BUILTIN("typeset", BINF_PLUSOPTS | BINF_MAGICEQUALS | BINF_PSPECIAL, bin_typeset, 0, -1, 0, "AE:%F:%HL:%R:%TUZ:%afghi:%klprtuxmzn", NULL),
     BUILTIN("umask", 0, bin_umask, 0, 1, 0, "S", NULL),
     BUILTIN("unalias", 0, bin_unhash, 1, -1, 0, "ms", "a"),
     BUILTIN("unfunction", 0, bin_unhash, 1, -1, 0, "m", "f"),
@@ -2369,6 +2369,11 @@ bin_typeset(char *name, char **argv, Options ops, int func)
 	else if (OPT_PLUS(ops,optval))
 	    off |= bit;
     }
+    if (OPT_MINUS(ops,'n')) {
+	on |= PM_FAKENAMEREF;
+    } else if (on || OPT_PLUS(ops,'n')) {
+	off |= PM_FAKENAMEREF;
+    }
     roff = off;
 
     /* Sanity checks on the options.  Remove conflicting options. */
diff --git a/Src/subst.c b/Src/subst.c
index a2bb648..842eb03 100644
--- a/Src/subst.c
+++ b/Src/subst.c
@@ -2237,9 +2237,11 @@ paramsubst(LinkList l, LinkNode n, char **str, int qt, int pf_flags)
 	while (inull(*s))
 	    s++;
 	v = (Value) NULL;
-    } else if (aspar) {
+    } else if (aspar || ((s = itype_end(s, IIDENT, 0)) && !*s)) {
+	struct value vtmp;
+	char *stmp = s = idbeg;
 	/*
-	 * No subexpression, but in any case the value is going
+	 * No subexpression, but in any case the value may be going
 	 * to give us the name of a parameter on which we do
 	 * our remaining processing.  In other words, this
 	 * makes ${(P)param} work like ${(P)${param}}.  (Probably
@@ -2247,12 +2249,20 @@ paramsubst(LinkList l, LinkNode n, char **str, int qt, int pf_flags)
 	 * and it's been kludged into the subexp code because no
 	 * opportunity for a kludge has been neglected.)
 	 */
-	if ((v = fetchvalue(&vbuf, &s, 1, (qt ? SCANPM_DQUOTED : 0)))) {
-	    val = idbeg = getstrvalue(v);
-	    subexp = 1;
-	} else
+	if ((v = fetchvalue(&vtmp, &stmp, 1, (qt ? SCANPM_DQUOTED : 0)))) {
+	    if (aspar || (v->pm->node.flags & PM_FAKENAMEREF)) {
+		s = stmp;
+		vbuf = vtmp;
+		val = idbeg = getstrvalue(v);
+		aspar = subexp = 1;
+	    }
+	} else if (aspar)
 	    vunset = 1;
-    }
+	if (!aspar) {
+	    v = (Value) NULL;
+	}
+    } else
+	s = idbeg;
     /*
      * We need to retrieve a value either if we haven't already
      * got it from a subexpression, or if the processing so
diff --git a/Src/zsh.h b/Src/zsh.h
index 94e9ffc..dfd9c53 100644
--- a/Src/zsh.h
+++ b/Src/zsh.h
@@ -1661,6 +1661,7 @@ struct tieddata {
 
 #define PM_KSHSTORED	(1<<17) /* function stored in ksh form              */
 #define PM_ZSHSTORED	(1<<18) /* function stored in zsh form              */
+#define PM_FAKENAMEREF	(1<<19) /* behaves like a ksh nameref, sort of      */
 
 /* Remaining flags do not correspond directly to command line arguments */
 #define PM_LOCAL	(1<<21) /* this parameter will be made local        */

Re: Partial implementation of "nameref", sort of.

[Oliver Kiddle]

Bart wrote:
> This is incomplete, but presented for consideration of how to proceed
> with it.

This is storing the string reference to the name, right? That is also
what the somewhat more complete implementation from back in 15058 did
except that also recorded the local level so a nameref to a local
variable from a calling function would work. I could rebase that patch
if it would be useful? I've also got a file of test cases from the time.

At the time, my understanding of the consensus was that an
implementation needed to instead use a pointer as the internal
representation of the reference (along with either reference counting or
garbage collection). Certain features in the ksh implementation are hard
to implement otherwise (e.g. reference to an unset variable). For that
to work, the parameter code (at least as it then stood) needed a certain
amount of refactoring. I think certain typeset options result(ed) in the
parameter being destroyed and created anew.

It's a more useful feature in Ksh which has lexically scoped local
variables. Ksh special cases nameref ref=$1 to take the referenced
parameter from the parent scope which seems quite ugly to me. I'd prefer
something more explicit like Tcl's uplevel command.

Oliver

Re: Partial implementation of "nameref", sort of.

[Bart Schaefer]

On Jan 26, 11:05pm, Oliver Kiddle wrote:
}
} This is storing the string reference to the name, right? That is also
} what the somewhat more complete implementation from back in 15058 did

Indeed, I'd forgotten all about that.

I saw the shortcut that seemed to be possible by simply setting aspar
in paramsubst() and decided to see what I could do with it.

} At the time, my understanding of the consensus was that an
} implementation needed to instead use a pointer as the internal
} representation of the reference

There's now a tmpdata pointer in the Param struct which may not have been
present in 2001.  Perhaps it could be leveraged for this.

} (along with either reference counting or garbage collection).

Yeah, that's the tricky bit -- finding the namerefs in the event the
pointed-to variable is unset or goes out of scope.  There'd have to be
an intermediate struct that points in both directions, or something.

} It's a more useful feature in Ksh which has lexically scoped local
} variables. Ksh special cases nameref ref=$1 to take the referenced
} parameter from the parent scope which seems quite ugly to me. I'd prefer
} something more explicit like Tcl's uplevel command.

Agreed.

probably nothing 'segmentation fault'

[Ray Andrews]

I got a seg fault that crashed geany, but it was while hot swapping the 
working font which I was in the process of editing, so it's hardly 
surprising that geany crashed, tho I'd not expect it's zsh's fault.  
Probably not an issue.  BTW, if anyone is interested, after looking at 
various fonts for the best 'programmer's font' I decided to make my own, 
featuring robustly differentiated characters, eg. two single quotes 
can't be mistaken for a double quote, 1Il| are unconfusable, the period 
is bigger so I might stop trying to source binaries, etc.  If anyone 
wants, contact me privately.

Re: probably nothing 'segmentation fault'

[Peter Stephenson]

On Tue, 27 Jan 2015 09:13:34 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> I got a seg fault that crashed geany, but it was while hot swapping the 
> working font which I was in the process of editing, so it's hardly 
> surprising that geany crashed, tho I'd not expect it's zsh's fault.  

Feel free of course to report potential bugs, but if you do you need to
supply at least basic context information about what you were doing.
All we know is that you were using something or other called geany.
There is an implication here it has something to do with zsh but I don't
know what.

You need to say something like:

- I was using geany, a programme which does x and which runs zsh as a
subprocess to do y.

- At the time of the crash zsh was [sitting idle at the editing command
line at a guess?  The less I have to guess the better.]

- I issued the following command / picked the following menu item ....
blah ...

- This caused zsh to crash or misbehave.

We might *still* not be able to do anything about it, but it now
contains at least the basis of a bug report.

Hope this is useful.

pws

Re: probably nothing 'segmentation fault'

[Ray Andrews]

On 01/27/2015 09:52 AM, Peter Stephenson wrote:
> On Tue, 27 Jan 2015 09:13:34 -0800
> Ray Andrews <rayandrews@eastlink.ca> wrote:
>> I got a seg fault that crashed geany, but it was while hot swapping the
>> working font which I was in the process of editing, so it's hardly
>> surprising that geany crashed, tho I'd not expect it's zsh's fault.
> Feel free of course to report potential bugs, but if you do you need to
> supply at least basic context information about what you were doing.
> All we know is that you were using something or other called geany.
> There is an implication here it has something to do with zsh but I don't
> know what.
Sorry Peter, I'm so sure it's not zsh's fault that I'm mentioning it in 
passing just in case anyone shows the slightest interest, at which point 
details would follow.  It is just remotely possible that someone would 
say "zsh shouldn't be reporting a seg fault due to some other program 
crashing, tell us more."  But you can hardly edit a working font under a 
running program without that causing trouble so I spare the details.  
Probably shouldn't have posted that at all. However it is the first time 
I've ever seen a seg fault that wasn't due to my own tinkering. Things 
crash, but zsh has never had anything to say about it before this.

geany is a quite nice GUI IDE/editor.