rcexpandparam fix

[Peter Stephenson <pws@xxxxxx>]

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@xxxxxx>       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.