Re: [9fans] equality sign in Rc

[erik quanstrom]

> You can force rc to setting a variable only if = is surrounded by spaces, 
> like in sh, but then you'll have a lot of problems in plan9/p9p.

nack.  disregarding the confusion about spaces, incompatible changes aren't ok.
i've heard the argument that one can't make language progress without breaking 
things.
c is a counter example.  so far, rc has been as well.

- erik

Re: [9fans] equality sign in Rc

[erik quanstrom]

On Sun May 14 08:32:47 PDT 2017, trebol55...@yandex.ru wrote:
>  > That isn't sh's rule. x=y is fine as an assignment without spaces.
> 
> Yes, sorry, in fact I was thinking on the contrary I wrote: don't set a 
> variable like in sh.
> 
> I like the use of spaces permitted in rc, as I said.

i was about to make this correction myself.  in any event, this is a sloppy but 
effective pure extension
to the grammar that allows everything but the first word to contain an '='.

since this is done at the grammar level, and not as one would expect at the 
lexer level, there are some
surprises like a function with "echo x=1" will deparse as echo 'x='^1.  not 
perfect, but workable

here's the code change

../rc/syn.y:24,35 - syn.y:24,47
return !i;
  }
  
+ tree*
+ treeeq(int type, tree *c0, tree *c1)
+ {
+   char *old;
+ 
+   old = c0->str;
+   c0->str = smprint("%s=", c0->str);
+   c0->quoted = 1;
+   free(old);
+   return tree2(type, c0, c1);
+ }
+ 
  %}
  %union{
struct tree *tree;
  };
  %type line paren brace body cmdsa cmdsan assign epilog redir
- %type cmd simple first word nkword comword keyword nkwords words wordsnl
+ %type cmd simple first nexteq word nkword comword keyword nkwords words 
wordsnl
  %type NOT FOR IN WHILE IF TWIDDLE BANG SUBSHELL SWITCH FN BREAK
  %type WORD REDIR DUP PIPE
  %%
../rc.me5/syn.y:84,89 - syn.y:96,102
  | FN nkwords brace{$$=tree2(FN, $2, $3);}
  | FN nkwords  {$$=tree1(FN, $2);}
  simple:   first
+ | simple nexteq   {$$=tree2(ARGLIST, $1, $2);}
  | simple word {$$=tree2(ARGLIST, $1, $2);}
  | simple redir{$$=tree2(ARGLIST, $1, $2);}
  first:comword 
../rc.me5/syn.y:111,113 - syn.y:124,127
  | words word  {$$=tree2(WORDS, $1, $2);}
  nkwords:  {$$=(struct tree*)0;}
  | nkwords nkword  {$$=tree2(WORDS, $1, $2);}
+ nexteq:   word '=' word   {$$=treeeq('^', $1, $3);}

here are some test cases

; ./o.rc
broken! x=1 echo $x
1
broken! whatis zot
zot: not found
broken! zot=1 echo $zot
1
broken! whatis one
one: not found
broken! one=1 two=2 echo $one $two
1 2
broken! echo one=1
one=1
broken! echo if=1
if=1
broken! fn eq {echo one=1 two=2}
broken! eq
one=1 two=2

- erik

Re: [9fans] equality sign in Rc

[trebol]

> I see. It seems that you know the code very well. If the variable assignments 
> are only before a command, why not permit =
> after the command? Do you know if is there a thought reason for that?

More precisely, "after the start of the command".

Re: [9fans] equality sign in Rc

[trebol]

 > That isn't sh's rule. x=y is fine as an assignment without spaces.

Yes, sorry, in fact I was thinking on the contrary I wrote: don't set a 
variable like in sh.

I like the use of spaces permitted in rc, as I said.

> [...] Shell/environment variable assignments appear only before a command, as 
> in rc,
> and otherwise the text gets passed to the command.[...] 
> In rc, the unquoted = causes a syntax error because nothing in syn.y allows 
> '=' after the start of 

I see. It seems that you know the code very well. If the variable assignments 
are only before a command, why not permit =
after the command? Do you know if is there a thought reason for that?

> Perhaps instead of passing it to the command as in Unix, rc could do what sh 
> originally intended, and lift named parameters
> into the environment wherever they appear in a command.

I think that the cleanest approach is to work with whatever you want to pass to 
a command, and then pass the result in a
not confusing way.
Variables are just fine, and with rc's lists of strings there is not need for 
more. The use of = in command arguments
should be prohibited (by law!).

By the way, do you know how this was designed in the original rc for v10 
research unix?

I looked some time ago in

   http://www.tuhs.org/Archive/Distributions/Research/

but there is no source of rc, only documentation.

trebol.

Re: [9fans] equality sign in Rc

[Charles Forsyth]

On 13 May 2017 at 13:36, trebol  wrote:

> You can force rc to setting a variable only if = is surrounded by spaces,
> like in sh, but then you'll have a lot of problems in plan9/p9p.


That isn't sh's rule. x=y is fine as an assignment without spaces.
Shell/environment variable assignments appear only before a command, as in
rc,
and otherwise the text gets passed to the command. As I understood Bourne's
talk about sh, originally it was intended to support named
parameters, as in another command interpreter he'd used, and in cmd x=y
b=x, the shell not the command would parse the x=y and b=x
and pass the result to the command separately from the positional
parameters of argv. That was modified to be allowed only at the start,
because of an existing command 'dd', which unusually used x=y instead of
the usual -x y, partly as humour, since IBM JCL then and now
had a DD statement with name=value syntax (//STEP5.INPUT DD
DSNAME=FRUITBAT,DISP=SHR)
``The maximum number of DD statements per job step is 3273''. Plan 9's dd's
syntax changed to the -x y style.

In rc, the unquoted = causes a syntax error because nothing in syn.y allows
'=' after the start of .
Perhaps instead of passing it to the command as in Unix, rc could do what
sh originally intended, and lift named parameters
into the environment wherever they appear in a command.