Re: saving bash.....

[Eric Blake]

On 08/10/2011 10:39 PM, Linda Walsh wrote:
> Chet Ramey wrote:
> > > If not, then wouldn't
> > > $((( ))) be turned into $( (( )) ), meaning the arith returns a
> > > status,
> > > and not the calculation. (I've tested this, and this is the case.
> Then I said:
>
> "It sounded to me like $(( )) would be translated into "$( (xxxx) )",
> turning off arithmetic expansion. Did I read that ___incorrectly__?

Yes, you read it incorrectly.

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.

> If not, [i.e. if I read it correctly] then wouldn't $((( ))) be turned
> into $( (( )) ), meaning the arith returns a status, and not
> the calculation. (I've tested this, and this is the case)."

Remember, $((body)) is treated as arithmetic expansion if body looks 
like arithmetic, and is only turned into $( (body)) otherwise (here, 
your body is '()').  POSIX' recommendation to add space is for the case 
of turning ambiguous $((body)) into definite command substitution $( 
(body)); you do not add space after the first '(' when you want arithmetic.

> ;-) ? (no insult intended! honest...just asking you (and others) to take
> a deep breath and not be reactive to what they think I'm am saying but
> try to focus on what I'm really "trying" (without great success,
> but I keep trying!) to say...

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 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.  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'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 '(())'.  That's life with 'set -e'; my 
advice has always been to avoid 'set -e' as a crutch and instead do 
error checking yourself, since 'set -e' behavior is unintuitive by design.

--
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org