On 4/24/17 3:59 AM, Florian Mayer wrote:
> Ok, I accept your points, but please read on and decide after that.
>
>> to do anything but assign a value to `var'. Very few people, when asked,
>> would say that it were more intuitive to cause a variable named `bar' to
>> spring into existence with th
It is essential to not break backward
compatibility. Imagine the huge number of scripts that would be
impacted by the semantic shift you're suggesting. If a proposal
were to be made that would cause backward incompatibility, then
any such proposal should be reject
Ok, I accept your points, but please read on and decide after that.
> to do anything but assign a value to `var'. Very few people, when asked,
> would say that it were more intuitive to cause a variable named `bar' to
> spring into existence with the value 7. If you want nameref behavior, you
> h
On 4/23/17 4:25 PM, Florian Mayer wrote:
>> That's not a reasonable expectation.
> Why not? Why is it not reasonable to expect an intuitive
> result from (())? The most intuitive thing, in my opinion,
> would be to use nameref for side effects by default, because in order
> to get a value from an i
On Sun, Apr 23, 2017 at 3:25 PM, Florian Mayer wrote:
[...]
> Why not? Why is it not reasonable to expect an intuitive
> result from (())? The most intuitive thing, in my opinion,
> would be to use nameref for side effects by default, because in order
> to get a value from an id, (()) already foll
> That's not a reasonable expectation.
Why not? Why is it not reasonable to expect an intuitive
result from (())? The most intuitive thing, in my opinion,
would be to use nameref for side effects by default, because in order
to get a value from an id, (()) already follows namerefs.
So if you have
On 4/23/17 8:28 AM, Florian Mayer wrote:
> What I’m saying is, that if bash does recursively apply expansion
> mechanisms on the identifiers until it can retrieve a number,
> it should do it symmetrically.
That's not a reasonable expectation.
Here's how it works. When bash reads a token, such a
> what shoud echo $((foo++)) do?
Give out an error message hopefully (and it does), because
the expression (bar+14+moo*2)++ makes no semantical sense
in terms of arithmetic expressions the bash uses, because ++
only can apply to locations and (bar+14+moo*2) evaluates to a number no matter
the con
On Sun, Apr 23, 2017 at 4:07 PM, Florian Mayer wrote:
> It does not matter, how this construct in this particular context is
> called.
> The difference between $(()) and (()) is that $(()) actually expands to
> something
> whereas (()) just executes a C-like expression. In (())
> can also
> incl
> And in my opinion those are not correct...
So in a scenario like the mentioned
$ foo=bar; bar=moo; moo=123
the line
$ ((foo++)); echo $foo $bar $moo
should actually evaluate to
„bar moo 124“
or at least say something like
„error, can not execute side effects, because I
can’t keep track of wha
It does not matter, how this construct in this particular context is called.
The difference between $(()) and (()) is that $(()) actually expands to
something
whereas (()) just executes a C-like expression. In (())
can also
include assignments, as the bash manual that you properly cited, also
e
On Sun, Apr 23, 2017 at 3:28 PM, Florian Mayer wrote:
> What I’m saying is, that if bash does recursively apply expansion
> mechanisms on the identifiers until it can retrieve a number,
> it should do it symmetrically. That is,
> it should remember what chain of expansion had been necessary for
>
What I’m saying is, that if bash does recursively apply expansion
mechanisms on the identifiers until it can retrieve a number,
it should do it symmetrically. That is,
it should remember what chain of expansion had been necessary for
a particular number to appear at the end of the expansion.
So i
On Sun, Apr 23, 2017 at 1:12 PM, Florian Mayer wrote:
> Consider
>
> $ foo=bar; bar=moo; moo=123
> $ echo $foo $bar $moo
> => bar moo 123
> $ echo $((foo))
> => 123
> $ echo $foo $bar $moo
> => bar moo 123
> $ # so far so good but
> $ ((foo++))
> $ echo $foo $bar $moo
> => 123 moo 123
>
> Now my
Consider
$ foo=bar; bar=moo; moo=123
$ echo $foo $bar $moo
=> bar moo 123
$ echo $((foo))
=> 123
$ echo $foo $bar $moo
=> bar moo 123
$ # so far so good but
$ ((foo++))
$ echo $foo $bar $moo
=> 123 moo 123
Now my chain of indirections is broken…
15 matches
Mail list logo
