Re: [9front] man rc patch

Re: [9front] man rc patch

[Alex Musolino]

Why not just fix it?  This patch [1] seems to do the trick for me.

Perhaps also worth mentioning is that $"1 is redundant, since $#1 is
always 1; just say $1.

[1] http://musolino.id.au/up/rcquote.patch

--
Cheers,
Alex Musolino

Re: [9front] man rc patch

[Ethan Gardener]

On Sun, Nov 11, 2018, at 6:59 AM, Alex Musolino wrote:
> Why not just fix it?  This patch [1] seems to do the trick for me.
> 
> Perhaps also worth mentioning is that $"1 is redundant, since $#1 is
> always 1; just say $1.

why add code to support something which doesn't make sense? :)  i thought it was a bug years ago, but then i realised there is no need for it.  unlike the bourne shell, rc doesn't have an obsession with breaking up strings.  once you've got a string in a variable, it's not going to be split again unless passed to eval.  in fact, supporting $"1 could be said to be deceitful, hiding this great feature from newcomers. ;)

Re: [9front] man rc patch

[Joe M]

> On Sun, Nov 11, 2018, at 6:59 AM, Alex Musolino wrote:
> > Why not just fix it?  This patch [1] seems to do the trick for me.
> >
> > Perhaps also worth mentioning is that $"1 is redundant, since $#1 is
> > always 1; just say $1.

Thanks for the patch.

> why add code to support something which doesn't make sense? :)  i thought it was a bug years ago, but then i realised there is no need for it.  unlike the bourne shell, rc doesn't have an obsession with breaking up strings.  once you've got a string in a variable, it's not going to be split again unless passed to eval.  in fact, supporting $"1 could be said to be deceitful, hiding this great feature from newcomers. ;)

I am trying to avoid the 'rc: null list in evaluation' messages when
using $1 when there is no first argument.

The $"1 outputs a blank string instead of failing with that error
message.

Thanks

#!/bin/rc

fn t{
	echo '$1 is' $1
	echo '$"1 is' $"1
	echo '$#1 is' $#1
	echo '$2 is' $2
	echo '$"2 is' $"2
	echo '$#2 is' $#2
	echo 'testing concatenation of $1 '$2
}

t 100

; rc /tmp/test.rc
$1 is 100
$"1 is
$#1 is 1
$2 is
$"2 is
$#2 is 0
rc: null list in concatenation
;

Re: [9front] man rc patch

[Joe M]

having the $"n is handy, as one does not have to wrap it in an if
statement if (~ $#n 0) to avoid checking for null values.

Re: [9front] man rc patch

[Ethan Gardener]

On Sun, Nov 11, 2018, at 5:16 PM, Joe M wrote:
> having the $"n is handy, as one does not have to wrap it in an if
> statement if (~ $#n 0) to avoid checking for null values.

oh yeah, that makes sense.

-- 
Progress might have been all right once, but it has gone on too long -- Ogden Nash

Re: [9front] man rc patch

[cinap_lenrek]

>>  +               if(star && 1<=n && n<=count(star)){
>>  +                       while(--n) star = star->next;
>>  +                       a = newword(star->word, a);
>>  +               }
> The condition is exactly the same as is in Xdol and it does work.
> I think you've misread it.

yes, its the same as Xdol(), thats precisely the problem. i was
refering to the use of $" to avoid checking for null list manually:

>>> having the $"n is handy, as one does not have to wrap it in an if
>>> statement if (~ $#n 0) to avoid checking for null values.

term% *=(1)
term% echo $#1
1
term% echo $#2
0
term% echo $1^$2
rc: null list in concatenation

--
cinap

Re: [9front] man rc patch

[Alex Musolino]

> but thats not what the patch is doing :-)
> 
>  +               if(star && 1<=n && n<=count(star)){
>  +                       while(--n) star = star->next;
>  +                       a = newword(star->word, a);
>  +               }
>
> this means for $"n where n is out of range, it would still
> yield a null list.

The condition is exactly the same as is in Xdol and it does work.
I think you've misread it.

In any case, your solution is almost certainly better.  I did think
about how to avoid the extraneous copying but didn't (an still don't)
know enough of the rc internals to get there.

--
Cheers,
Alex Musolino

Re: [9front] man rc patch

[cinap_lenrek]

consider this approach: we remove the Xqdol() instruction
and instead add a Xqw() instruction that pops a word list
and then pushes the quoted string. $"x is handled as
Xmark, Xmark, ...x..., Xdol, Xqw

one optimization is that we just exchange pointers when
the wordlist consists of just one item, avoiding the
string copy/free/alloc.

does this make sense?

diff -r f1e9a71d650a sys/src/cmd/rc/code.c
--- a/sys/src/cmd/rc/code.c	Wed Nov 14 09:12:34 2018 +0100
+++ b/sys/src/cmd/rc/code.c	Thu Nov 15 20:10:15 2018 +0100
@@ -96,8 +96,10 @@
 		break;
 	case '"':
 		emitf(Xmark);
+		emitf(Xmark);
 		outcode(c0, eflag);
-		emitf(Xqdol);
+		emitf(Xdol);
+		emitf(Xqw);
 		break;
 	case SUB:
 		emitf(Xmark);
diff -r f1e9a71d650a sys/src/cmd/rc/exec.c
--- a/sys/src/cmd/rc/exec.c	Wed Nov 14 09:12:34 2018 +0100
+++ b/sys/src/cmd/rc/exec.c	Thu Nov 15 20:10:15 2018 +0100
@@ -233,7 +233,7 @@
  * Xdelfn(name)				delete function definition
  * Xdeltraps(names)			delete named traps
  * Xdol(name)				get variable value
- * Xqdol(name)				concatenate variable components
+ * Xqw(words)				quote word list
  * Xdup[i j]				dup file descriptor
  * Xexit				rc exits with status
  * Xfalse{...}				execute {} if false
@@ -697,18 +697,22 @@
 }
 
 void
-Xqdol(void)
+Xqw(void)
 {
 	char *s;
 	word *a;
-	if(count(runq->argv->words)!=1){
-		Xerror1("variable name not singleton!");
+
+	a = runq->argv->words;
+	if(a && a->next == 0){
+		runq->argv->words = 0;
+		poplist();
+		a->next = runq->argv->words;
+		runq->argv->words = a;
 		return;
 	}
-	s = Str(runq->argv->words);
-	a = vlook(s)->val;
+	s = list2str(a);
 	poplist();
-	Pushword(list2str(a));
+	Pushword(s);
 }
 
 word*
diff -r f1e9a71d650a sys/src/cmd/rc/exec.h
--- a/sys/src/cmd/rc/exec.h	Wed Nov 14 09:12:34 2018 +0100
+++ b/sys/src/cmd/rc/exec.h	Thu Nov 15 20:10:15 2018 +0100
@@ -2,7 +2,7 @@
  * Definitions used in the interpreter
  */
 extern void Xappend(void), Xasync(void), Xbackq(void), Xbang(void), Xclose(void);
-extern void Xconc(void), Xcount(void), Xdelfn(void), Xdol(void), Xqdol(void), Xdup(void);
+extern void Xconc(void), Xcount(void), Xdelfn(void), Xdol(void), Xqw(void), Xdup(void);
 extern void Xexit(void), Xfalse(void), Xfn(void), Xfor(void), Xglob(void);
 extern void Xjump(void), Xmark(void), Xmatch(void), Xpipe(void), Xread(void);
 extern void Xrdwr(void);
diff -r f1e9a71d650a sys/src/cmd/rc/pfnc.c
--- a/sys/src/cmd/rc/pfnc.c	Wed Nov 14 09:12:34 2018 +0100
+++ b/sys/src/cmd/rc/pfnc.c	Thu Nov 15 20:10:15 2018 +0100
@@ -50,7 +50,7 @@
 	Xglobs, "Xglobs",
 	Xrdfn, "Xrdfn",
 	Xsimple, "Xsimple",
-	Xqdol, "Xqdol",
+	Xqw, "Xqw",
 0};
 
 void

--
cinap

Re: [9front] man rc patch

[cinap_lenrek]

but thats not what the patch is doing :-)

 +               if(star && 1<=n && n<=count(star)){
 +                       while(--n) star = star->next;
 +                       a = newword(star->word, a);
 +               }

this means for $"n where n is out of range, it would still
yield a null list.

also, i do not like how Xqdol() duplicates the logic.
it really should be two separate instructions. Xdol
doing the dereference of the variable, handling the special
star variables... and another instruction Xqote or something
that flattens it out to a single string where () becomes
the empty string.

--
cinap