Il 16 Maggio 2017 19:11:33 CEST, Kurt H Maier ha scritto:
>On Mon, May 15, 2017 at 03:32:09PM -0400, s...@9front.org wrote:
>> Honestly, the equality sign is never a problem for me.
>> What is the purpose again of making this change?
>>
>> sl
>
>Why won't anyone answer this
imo instead of changing = behavior * and ? should give errors like
following if unmatched.
rc: #d/0: token '*': syntax error
rc: #d/0: token '?': syntax error
On Mon, May 15, 2017 at 03:32:09PM -0400, s...@9front.org wrote:
> Honestly, the equality sign is never a problem for me.
> What is the purpose again of making this change?
>
> sl
Why won't anyone answer this question?
Is bikeshedding a minor inconvenience worth this kind of complexity?
khm
Tonight I've tried this little hack, but I do not have a comprehensive test
suite (does any exists?)
https://github.com/JehanneOS/jehanne/commit/003141901af25f0bb3556be40b7ff963f57ced32
I thought that there's no reason to mimic sh for this since if you need sh
to run a script rc won't work
by doing it in the grammar, the redirection issue is avoided.- erikOn May 16, 2017 2:24 AM, Charles Forsyth wrote:On 15 May 2017 at 17:44, trebol wrote:> = is part of rc syntax, like {} and (), and it interprets it, not thei'd forgotten about the
On 15 May 2017 at 17:44, trebol wrote:
> > = is part of rc syntax, like {} and (), and it interprets it, not the
i'd forgotten about the = in >[2=1], so you'd need another exception ...
rc would interpret that, but then in [a-b=] it presumably wouldn't again...
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
> $^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
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
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
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
Honestly, the equality sign is never a problem for me.
What is the purpose again of making this change?
sl
> 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
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.
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
> 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.
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
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
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
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
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
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
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.
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.
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
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
>
"c is a counter example"
I think he means the opposite.
> 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?
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
>
> 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
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
> 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".
> 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,
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
Well fix it! Can't be too hard.
brucee
On 14 May 2017 at 02:53, Charles Forsyth wrote:
>
> On 13 May 2017 at 15:21, trebol wrote:
>
>> No with hyphenation, my friend!
>
>
> ahh! that's a little more specific. I usually switch it off so I
On 13 May 2017 at 15:21, trebol wrote:
> No with hyphenation, my friend!
ahh! that's a little more specific. I usually switch it off so I wouldn't
have noticed.
No with hyphenation, my friend!
On 13 May 2017 at 13:36, trebol wrote:
> Then I used troff to write a paper, and surprise!, there is no utf8
> support.
I'm fairly sure there is in troff.
why do that when you can just run 'mk'
On May 6, 2017 12:47 AM, "Sean Callanan" wrote:
> I can't speak for dexen, but I would love to be able to run
>
> cc -DFOO=bar file.c
>
> or similar commands with button 2 in Acme. What I get instead is
>
> rc: line 2: token '=':
Sure, and that's the 'quoted equality sign' dexen was complaining about in
the first place.
When you're hand-writing a command it probably becomes muscle memory pretty
quickly, but for people who often copy-paste commands or run them straight
out of files, I'm sure they've been aggravated by this
i would have expected this to work:
cc '-DFOO=bar' file.c
-Steve
> On 6 May 2017, at 08:43, Sean Callanan wrote:
>
> I can't speak for dexen, but I would love to be able to run
>
> cc -DFOO=bar file.c
>
> or similar commands with button 2 in Acme. What I get instead
I can't speak for dexen, but I would love to be able to run
cc -DFOO=bar file.c
or similar commands with button 2 in Acme. What I get instead is
rc: line 2: token '=': syntax error
Sean
iPadから送信
2017/05/05 18:53、t...@teknik.io のメッセージ:
> May 1, 2017 2:30 PM, "dexen deVries"
May 1, 2017 2:30 PM, "dexen deVries" wrote:
> does anybody have a version of Rc that allows unquoted equality sign?
>
> having to quote the character get a bit annoying on POSIX systems (plan9port)
I don't, but can you explain in detail what you are doing that causes
44 matches
Mail list logo