Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

> 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

Re: [9fans] equality sign in Rc

> $^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

Re: [9fans] equality sign in Rc

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

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

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

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

> 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

Re: [9fans] equality sign in Rc

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.

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

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

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

Re: [9fans] Blocking on write

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

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

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

Re: [9fans] Blocking on write

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

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

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

Re: [9fans] Blocking on write

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

Re: [9fans] equality sign in Rc

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

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

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

Re: [9fans] equality sign in Rc

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 >

Re: [9fans] equality sign in Rc

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

Re: [9fans] equality sign in Rc

> 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

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

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

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 >