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 rejected unless there are truly
compelling reasons for the proposal. Now, if you're proposing some
new shopt (Bash-specific) or set -o (a broader set of sh shells)
that would deliver some alternative behavior, then at least you
wouldn't be breaking backward compatibility. However, any such
addition would complicate the test matrix for shell behavior and
should again be subject to very strong scrutiny and strong
community desire for such a feature. I'm not sensing that this is
the case for what you're describing.
Best regards,
Steve Amerige
Eggsh: A Bash-Scripting Platform
https://eggsh.com
On 4/24/2017 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 the value 7. If you want nameref
behavior, you
have to explicitly declare it.
But why is nameref behavior in the
evaluation part activated by default
and not for the assignments? I think that one should
either make nameref behavior the default case for
both,
assignment and evaluation, or the non-default case
for both.
In the latter case, where namerefs are off for both
things, the lines (1) and (2)
1) var=bar; bar=3; echo ((var))
2) var=bar; ((var=3)) or var=bar; bar=0; ((var++))
should lead to an error message!
However the current status quo is, that bash happily
does (1) as you’d
expect but gives out no error in (2) and overwrites
(1).
That is variable indirection.
It has superficially similar effects to what
we are discussing, which is arithmetic expansion; however, it
has nothing
to do with the behavior of (( )) or $(( )).
Again, I never wrote, that, from a technical point
of view, it has something to do
with (()) or $(()). Merely the visible behavior is
similar in the cases I showed.
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 id, (()) already follows
namerefs.
The thing that makes that result intuitive for you is your
opinion about
how things should work. That's fine. I don't happen to
share your opinion
of what is "intuitive" in this case.
However, it is unreasonable to expect
var=bar
((
var=7 ))
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
have to explicitly declare it.
It's not indirection,
and I am not sure why you show the completely
I was mentioning that, not because I use „a mental
model“ that falsely unifies
both things, but because I wanted to point out that
there exists something
with a similar behavior.
And if ${!<varid>} does not portray some kind of
indirection, what do you
call it then?
That is variable indirection. It has superficially similar
effects to what
we are discussing, which is arithmetic expansion; however,
it has nothing
to do with the behavior of (( )) or $(( )).