Re: saving bash.....(bash usefulness vs. being, orwellianly 'standardardized')

[Linda Walsh]

Eric Blake wrote:
> On 08/10/2011 10:39 PM, Linda Walsh wrote:
> > "It sounded to me like $(( )) would be translated into "$( (xxxx) )",
> > turning off arithmetic expansion. Did I read that ___incorrectly__?
>
> Yes, you read it incorrectly.
---
        *thankyou*

> POSIX is saying that _if_ you want to guarantee command substitution of 
> a subshell (that is, $() with a leading ( as the first item of the 
> command to run), then use spaces.  But if you want to guarantee 
> arithmetic expansion, then you _have_ to start with $((; and that if you 
> start with $((, then arithmetic expansion takes precedence.
----
        Got it!... Clear now, I wouldn't have thought otherwise,
but saw a ref the bug in a goog search for topics related to this(these)
issues (compatibility vs. posix compliance, and mission statements
or design purpose(s) of bash)...


> Same here - I think we're all trying to be civil and helpful, and while 
> emotions sometimes rise to the surface, hopefully everyone around is 
> recognizing the underlying fact that no one here is intentionally trying 
> to be malicious.
----
        I would hope not, though at times, though sometimes contrarianism
for no _apparent_ purpose, can appear so.



> > I don't find it useful to have (()) cause exceptions. It's not a useful
> > construct -- having it do so means it has to be programmed around.
>
> (()) is a useful construct, when used correctly; best designed for the 
> condition of a loop expression where the loop will terminate when the 
> count finally evaluates to 0.
---
Well...   I thought it was for evaluating mathematical expressions.
I thought it was useful instead of using 'let', for example, though
now 'let' has the same problem as (()).  If you do a calculation with
let a=0, and you have -e set, your shell or script will exit.

I'm sorry, but I'm going to need convincing that


      "let a=0"     is an error that should kill a script.


It's the same with:

((a=0))
---
        Simple math calculations like that aren't errors if they evaluate to 0
if the divide by 0 or overflow or something, ... yes, but returning a 
result
of '0' == error?





>  It does the same parsing and operation as 
> $(()), except that instead of resulting in numeric output, it results in 
> a change to $?.  And once you realize that (()) is the shorthand 
> counterpart to 'expr', and therefore has the same effect on $? (where 0 
> gives $?=1, non-zero gives $?=0, and error gives $?>1), then you can 
> properly use this extension.  Or, since it is an extension, you can just 
> avoid it altogether, and write scripts more portably.
----
        It didn't *used* malfunction that way.

        It wasn't treated as a command returning an error, but an
integer calculation.


> > It's not useful to have a function that is meant to return no value, --
> > if last calc'ed value was 0, to cause a script to fail....it may be
> > POSIX, but I'm looking for bash that was useful to write script in and
> > do some rudimentary programming with -- NOT a POSIX shell, I can get
> > from Microsoft or any other vendor.
>
> If you want to use 'set -e', then you have to deal with arithmetic 
> results of 0 setting $? to 1; whether the arithmetic results come from 
> traditional 'expr' or extension '(())'. 
----
**Exception**
declare -i a
a=0
--
        As a is declared to be an integer, it has the results evaluated
at assignment time.   a=0 is an integer expression that doesn't set
$?=1
Neither should:
((a=0))

They are not different, as 'a', declared with "-i" is evaluated
with "Arithmetic evaluation".
===quote===
 -i     The variable is treated as an integer; arithmetic evaluation
        (see ARITHMETIC EVALUATION above) is performed  when
        the variable is assigned a value.
====


> That's life with 'set -e'; my 
> advice has always been to avoid 'set -e' as a crutch
---
        set -e is a valuable development aid to ensure that all your *ERRORS*
are caught by the script, and not allowed to execute 'unhandled'.  It 
has never
been required to catch the value of '0' from arithmetic evaluations.  That
is something new that was just added that is doesn't make sense from
a devel standpoint.

        And I suppose you run your perl without "-w;use strict;" as they
are also crutches (or same w/any language that provides any level of
builtin sanity checking)...