* rcexpandparam fix
@ 1997-10-03 12:51 Peter Stephenson
1997-10-03 14:05 ` Zoltan Hidvegi
0 siblings, 1 reply; 2+ messages in thread
From: Peter Stephenson @ 1997-10-03 12:51 UTC (permalink / raw)
To: Zsh hackers list
This seems to be the minimal fix to the rcexpandparam bug. I think
the most general way it turned up was when rcexpandparam was set for
an array which expanded to no entries (i.e. not even an empty
string) and when there was some further expansion to be done on the line
(i.e. another parameter substitution further along, or a file substitution
anywhere). Thus `print ${^*} $*' printed the second $* verbatim, as well
as what I originally reported, that `=ls ${^*}' didn't expand =ls.
This only comes into effect in the case where the rcexpandparam did
fail with a NULL return, and simply setting the node to the empty
string has the correct effect of forcing it to be removed later.
Failure presumably indicates that the array was empty; the current
rules state that that means the whole term with the embedded array
is dropped, so this can't be too far wrong. The only way I can see
it would go wrong is if the plan9 expansion failed for some other reason
and a NULL should really be returned. I can't see how that would be
necessary.
*** Src/subst.c.plan9 Mon Aug 4 10:01:57 1997
--- Src/subst.c Fri Oct 3 14:27:02 1997
***************
*** 1429,1436 ****
insertlinknode(l, n, (void *) y), incnode(n);
}
if (plan9) {
! uremnode(l, n);
! return NULL;
}
} else {
x = aval[0];
--- 1429,1440 ----
insertlinknode(l, n, (void *) y), incnode(n);
}
if (plan9) {
! /* hello, I am a (lonely) comment.
! * If we did nothing with plan9 mode, simply
! * make the node empty: it will be removed later.
! */
! setdata(n, (void *) dupstring(""));
! return n;
}
} else {
x = aval[0];
--
Peter Stephenson <pws@ifh.de> Tel: +49 33762 77366
WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413
Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, Platanenallee 6, 15738 Zeuthen, Germany.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: rcexpandparam fix
1997-10-03 12:51 rcexpandparam fix Peter Stephenson
@ 1997-10-03 14:05 ` Zoltan Hidvegi
0 siblings, 0 replies; 2+ messages in thread
From: Zoltan Hidvegi @ 1997-10-03 14:05 UTC (permalink / raw)
To: Peter Stephenson; +Cc: zsh-workers
Peter Stephenson wrote:
> This seems to be the minimal fix to the rcexpandparam bug. I think
Even more minimal than you thought. It is really a kind of typo bug, so
bad, that such thing always turn out after a new release )-:. Here is the
fix.
Zoltan
diff -c subst.c.orig subst.c
*** Src/subst.c.orig Fri Sep 26 03:42:18 1997
--- Src/subst.c Fri Oct 3 16:00:10 1997
***************
*** 1439,1445 ****
}
if (plan9) {
uremnode(l, n);
! return NULL;
}
} else {
x = aval[0];
--- 1439,1445 ----
}
if (plan9) {
uremnode(l, n);
! return n;
}
} else {
x = aval[0];
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1997-10-03 14:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-10-03 12:51 rcexpandparam fix Peter Stephenson
1997-10-03 14:05 ` Zoltan Hidvegi
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).