bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: saving bash.....


From: Eric Blake
Subject: Re: saving bash.....
Date: Thu, 11 Aug 2011 05:41:11 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.11

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]