Re: [9fans] equality sign in Rc

[trebol]

So putting control characters aside, and space wich is not part of an unquoted 
word,
they are just one of "!\"#$%&'()+,-./:;<=>?@[\\]^`{|}~",
I'm looking in the wrong file, lex.c? If not, may be that explicit list would 
be nice in rio(1).

I'm going to study the code and shut up my mouth.

>> characters of the same type (c>' ' && 
>> !strchr("!\"#$%&'()+,-./:;<=>?@[\\]^`{|}~", c)) should be skipped too,
> 
> I'm making a mess again...
> 
> the type I'm talking about is chars that don't match that expression, I 
> suppose that not matching
> that expression is what is used for
> 
> "character other than an alphanumeric, underscore, or *".
> 
> trebol.

Re: [9fans] equality sign in Rc

[trebol]

> characters of the same type (c>' ' && 
> !strchr("!\"#$%&'()+,-./:;<=>?@[\\]^`{|}~", c)) should be skipped too,

I'm making a mess again...

the type I'm talking about is chars that don't match that expression, I suppose 
that not matching 
that expression is what is used for 

"character other than an alphanumeric, underscore, or *".

trebol.

Re: [9fans] equality sign in Rc

[trebol]

> $^x is a syntax error, and not $x.
> $^x would be "whatever $ is" concatenated with literal "x"
> but "$" by itself is a syntax error

That's my point!

$-fu should be a syntax error, because is (our should be) equivalent
to $^-fu, an incorrect expression.

>From rc(1)
[...]
If  an unquoted word immediately follows a $ and contains a
character other than an alphanumeric, underscore, or *, a ^ is inserted
before the first such character.
[...]

But rc, I suppose, skip the first char next to $ in the search of a not 
alphanumeric, not * ... character.
If this is not a bug, but a feature, then it must be explained in rc(1), and 
for me, all the contiguous
characters of the same type (c>' ' && 
!strchr("!\"#$%&'()+,-./:;<=>?@[\\]^`{|}~", c)) should be skipped too,
so $--fu would be also correct.

For me the best is making $-fu a syntax error, and let the programmer decide if 
such an awkward name is
worthy of typing quotes everywhere.

trebol

Re: [9fans] equality sign in Rc

[Charles Forsyth]

On 15 May 2017 at 19:33, trebol  wrote:

> $-fu must be equivalent to $^-fu,


$^x is a syntax error, and not $x.
$^x would be "whatever $ is" concatenated with literal "x"
but "$" by itself is a syntax error

Re: [9fans] equality sign in Rc

[Charles Forsyth]

On 15 May 2017 at 17:44, trebol  wrote:

> I suppose this is the perfect answer to my silly question: why not permit =
> after the start of a command?
>

do that, but make it behave like = before the start of the command.
rc provides the outer syntax for all commands, as it does for file matching
and redirection.
the commands receive argv[], and (in Plan 9) /env as before.
rc puts positional word arguments in argv, which are identified by
position, and assignments in /env, which is what it currently does for x=y
before a command (or before no command).

Re: [9fans] equality sign in Rc

[Erik Quanstrom]

my purpose was to answer the question posed in the list.  iirc, rsc proposed this solution as well.  I have to mention that this is no funkier than allowing "echo if", which rc does.  I also have to mention that I'm not yet convinced of this change.  but it sure is no fun to quote every arg to certain programs.- erik

Re: [9fans] equality sign in Rc

[sl]

Honestly, the equality sign is never a problem for me.
What is the purpose again of making this change?

sl

Re: [9fans] equality sign in Rc

[trebol]

> This is not sh, use $'--fu'.
> Any way, is this a bug?

I mean, following the man page, $-fu must be equivalent to $^-fu, and give a 
syntax error. The first of those
characters (not alphanumeric, or * ...) is skiping the trap!

Anyway, I'm out of this conversation: I haven't study the code, so I'm talking 
rubbish.

trebol.

Re: [9fans] equality sign in Rc

[Giacomo Tesio]

Ok, sorry... :-)

However what about disallowing '-'  as variable's name starting character?

It would be a breaking change, but probably more in theory than in practice.
However options like -Da=1 and --foo=bar could then work unquoted.

To my untrained eye, the gain seems larger than the loss.
Am I missing an obvious use case? Or maybe the changes to rc's code would
be too complex?


Giacomo

Il 15/Mag/2017 18:39, "Charles Forsyth"  ha
scritto:

>
> On 15 May 2017 at 17:30, Giacomo Tesio  wrote:
>
>> % echo "$--fu"
>> rc: null list in concatenation
>>
>
> wrong quotes. try echo $'--fu'
>
> h% --x=hello
> h% echo $'--x'
> hello
>
>

Re: [9fans] equality sign in Rc

[trebol]

On Mon, 15 May 2017 16:59:45 +0100
Charles Forsyth  wrote:

> It would be better then to leave things as they are.
> = is part of rc syntax, like {} and (), and it interprets it, not the
> commands, unless quoted.

I suppose this is the perfect answer to my silly question: why not permit =
after the start of a command?

As I said, = in command arguments should be prohibited!

trebol.

Re: [9fans] equality sign in Rc

[trebol]

> Actually a --fu variable is not that useful in Plan 9:
> 
> % --fu=bar
> % echo $--fu
> rc: null list in concatenation
> % echo "$--fu"
> rc: null list in concatenation
> % ls /env
> '/env/*'
> /env/--fu
> ...
> 
> So rc can create a variable starting with more than one '-', but can't use it.

This is not sh, use $'--fu'.
Any way, is this a bug?

Re: [9fans] equality sign in Rc

[Charles Forsyth]

On 15 May 2017 at 17:30, Giacomo Tesio  wrote:

> % echo "$--fu"
> rc: null list in concatenation
>

wrong quotes. try echo $'--fu'

h% --x=hello
h% echo $'--x'
hello

Re: [9fans] equality sign in Rc

[Giacomo Tesio]

Actually a --fu variable is not that useful in Plan 9:

% --fu=bar
% echo $--fu
rc: null list in concatenation
% echo "$--fu"
rc: null list in concatenation
% ls /env
'/env/*'
/env/--fu
...

So rc can create a variable starting with more than one '-', but can't use
it.

So I wonder if there is a definition of "the right thing" that can fix this
incongruence and also allow the UNIX usage.


Giacomoec


2017-05-15 17:59 GMT+02:00 Charles Forsyth :

>
> On 15 May 2017 at 16:54, Erik Quanstrom  wrote:
>
>> if we implement the right thing, then arguments like --fu=bar will be
>> 'eaten silently' from the perspective of the (human) operator.  sure gigo,
>> but this seems extra hard o get right in a Unix environment.
>
>
> It would be better then to leave things as they are.
> = is part of rc syntax, like {} and (), and it interprets it, not the
> commands, unless quoted.
>

Re: [9fans] Blocking on write

[Charles Forsyth]

On 15 May 2017 at 16:46, Giacomo Tesio  wrote:

> Shouldn't the waserror code check that the queue has been actually closed?


Either that or check errstr against Ehungup, since that's the exact error
it incurred.
The latter has the advantage of not obscuring a different error if the pipe
is closed
between the write and waserror, but with pipes there's not much except
interrupt, I suppose,
so it seems a minor race and perhaps the qclosed check is adequate.

Re: [9fans] equality sign in Rc

[Charles Forsyth]

On 15 May 2017 at 16:54, Erik Quanstrom  wrote:

> if we implement the right thing, then arguments like --fu=bar will be
> 'eaten silently' from the perspective of the (human) operator.  sure gigo,
> but this seems extra hard o get right in a Unix environment.


It would be better then to leave things as they are.
= is part of rc syntax, like {} and (), and it interprets it, not the
commands, unless quoted.

Re: [9fans] equality sign in Rc

[Erik Quanstrom]

there is no winning.if we implement the right thing, then arguments like --fu=bar will be 'eaten silently' from the perspective of the (human) operator.  sure gigo, but this seems extra hard o get right in a Unix environment.- erikOn May 15, 2017 08:42, Charles Forsyth  wrote:On 15 May 2017 at 16:37, Erik Quanstrom  wrote:I implemented the Unix mistake as this hack is for p9p.  I'm not sure I like it.  it's interesting to note that = is still not allowed in a list.Great. So now there are two different rc conventions.perhaps {} should be treated specially after the first word so find can be used.

Re: [9fans] Blocking on write

[Giacomo Tesio]

I've just noticed a strange behaviour in devpipe that occurs on both
9front and Plan 9.

When the write blocks, if a note interrupt the process, the waserror
in pipewrite and pipebwrite will post another note that says "sys:
write on a closed pipe ..."

However the pipe is actually open, and still works, as you can see in
the attached test.

Shouldn't the waserror code check that the queue has been actually closed?


Giacomo

2017-05-15 15:36 GMT+02:00 Giacomo Tesio :
> Thanks Charles!
>
>
> Giacomo
>
> 2017-05-15 12:32 GMT+02:00 Charles Forsyth :
>>
>> On 15 May 2017 at 11:05, Giacomo Tesio  wrote:
>>>
>>> Is there any fs/device in Plan9 that can easily provide such behaviour?
>>
>>
>> Bind #| to a name and fill up one of the data files (blocks at 256k on my
>> system, might be 32k on small ones).
#include 
#include 

int
writeTillBlock(int fd)
{
	int i = 0;
	char buf[1024];
	memset(buf, 1, sizeof(buf));
	while(i < 300){
		if(write(fd, buf, sizeof(buf)) < 0)
			break;
		print("%d\n",i);
		++i;
	}
	return i;
}

int
continueOnAlarm(void *v, char *s)
{
	if(strncmp(s, "alarm", 5) == 0)
		return 1;
	if(strncmp(s, "sys: write on closed pipe", 25) == 0)
		return 1;
	return 0;
}

void
main(void)
{
	int fds[2], res;
	char buf[1024];

	pipe(fds);

	atnotify(continueOnAlarm, 1);

	alarm(1);
	res = writeTillBlock(fds[0]);

	if(res < 256){
		while(res > 1){
			read(fds[1], buf, sizeof(buf));
			--res;
		}
		if(write(fds[0], buf, sizeof(buf)) < 0){
			print("FAIL: can't write after reads: %r\n");
			exits("FAIL");
		}
		print("PASS\n");
		exits(nil);
	}else{
		print("FAIL: written %d kb\n", res);
		exits("FAIL");
	}
	
}

Re: [9fans] equality sign in Rc

[Charles Forsyth]

On 15 May 2017 at 16:37, Erik Quanstrom  wrote:

> I implemented the Unix mistake as this hack is for p9p.  I'm not sure I
> like it.  it's interesting to note that = is still not allowed in a list.


Great. So now there are two different rc conventions.
perhaps {} should be treated specially after the first word so find can be
used.

Re: [9fans] equality sign in Rc

[Erik Quanstrom]

yes.  nothing can break.I implemented the Unix mistake as this hack is for p9p.  I'm not sure I like it.  it's interesting to note that = is still not allowed in a list.- erikOn May 15, 2017 04:56, Charles Forsyth  wrote:On 15 May 2017 at 12:54, Charles Forsyth  wrote:and = would be handled by rc uniformly.It also wouldn't break anything, because nothing currently can use unquoted =,and things that used quoted = would work just as before.

Re: [9fans] Blocking on write

[Giacomo Tesio]

Thanks Charles!


Giacomo

2017-05-15 12:32 GMT+02:00 Charles Forsyth :
>
> On 15 May 2017 at 11:05, Giacomo Tesio  wrote:
>>
>> Is there any fs/device in Plan9 that can easily provide such behaviour?
>
>
> Bind #| to a name and fill up one of the data files (blocks at 256k on my
> system, might be 32k on small ones).

Re: [9fans] equality sign in Rc

[Charles Forsyth]

On 15 May 2017 at 12:54, Charles Forsyth  wrote:

> and = would be handled by rc uniformly.


It also wouldn't break anything, because nothing currently can use unquoted
=,
and things that used quoted = would work just as before.

Re: [9fans] equality sign in Rc

[Charles Forsyth]

On 15 May 2017 at 12:54, Charles Forsyth  wrote:

> = would be handled by rc uniformly.


Just as file name patterns are handled by the shell for all commands.

Re: [9fans] equality sign in Rc

[Charles Forsyth]

The original aim was to implement named parameters that the shell would
parse and pass to the command.
That was frustrated in UNIX because there was one command (dd) that used =
in its syntax.
There are no such commands in Plan 9, except mk, but mk is interesting
because
mk treats those as entries into the environment, so the thing you
originally complained about
would work without quoting, and = would be handled by rc uniformly.

On 15 May 2017 at 12:48, trebol  wrote:

> Why? the assignment is after the start of the command, so is not an
> assignment,
> and with the correction of Erik, now rc admit the use of = after the first
> word
> (in the first would be an assignment), so two=2 is just an argument to
> echo,
> exactly 'two='2.
>
> I like this behavior.
>
> trebol
>
> > Given
> >
> >> broken! one=1 two=2 echo $one $two
> >>
> >> 1 2
> >
> > What should the following do?
> >
> > one=1 echo two=2 $one $two
> >
> > Disregarding a UNIX historical mistake, I'd expect
> > 1 2
>
>

Re: [9fans] equality sign in Rc

[trebol]

Why? the assignment is after the start of the command, so is not an assignment,
and with the correction of Erik, now rc admit the use of = after the first word
(in the first would be an assignment), so two=2 is just an argument to echo,
exactly 'two='2.

I like this behavior.

trebol

> Given
> 
>> broken! one=1 two=2 echo $one $two
>>
>> 1 2
> 
> What should the following do?
> 
> one=1 echo two=2 $one $two
> 
> Disregarding a UNIX historical mistake, I'd expect
> 1 2

Re: [9fans] equality sign in Rc

[trebol]

"c is a counter example"
I think he means the opposite.

Re: [9fans] equality sign in Rc

[hiro]

> i've heard the argument that one can't make language progress without
> breaking things.
> c is a counter example.

what has been changed in c that you are referring to?

Re: [9fans] Blocking on write

[Charles Forsyth]

On 15 May 2017 at 11:05, Giacomo Tesio  wrote:

> Is there any fs/device in Plan9 that can easily provide such behaviour?


Bind #| to a name and fill up one of the data files (blocks at 256k on my
system, might be 32k on small ones).

[9fans] Blocking on write

[Giacomo Tesio]

Hi, to write a test I'm looking for an easy way to have a write()
blocking forever.

Is there any fs/device in Plan9 that can easily provide such behaviour?


Giacomo

Re: [9fans] equality sign in Rc

[Charles Forsyth]

Given

> broken! one=1 two=2 echo $one $two
> 1 2
>

What should the following do?

  one=1 echo two=2 $one $two

Disregarding a UNIX historical mistake, I'd expect
   1 2


> broken! echo one=1
> one=1
>