bug-bash
[Top][All Lists]
Advanced

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

Re: Another new 4.0 feature? functions can't return '1', (()) can't eval


From: Linda Walsh
Subject: Re: Another new 4.0 feature? functions can't return '1', (()) can't eval to 0?
Date: Tue, 09 Aug 2011 17:10:41 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666



Chet Ramey wrote:
On 8/8/11 11:43 PM, Linda Walsh wrote:
I have a function that returns true/false.

during development, (and sometimes thereafter depending on the script, I
run with -eu, to make sure the script stops as soon as there is a
problem (well, to 'try' to make sure, many are caught.

But there are two instances that cause an error exit that seem pretty
unuseful and I don't remember them breaking this way before.

The change to make (( honor the `errexit' option came in with bash-4.1,
part of the cleanup after the Posix changes to the specification of the
behavior of `set -e'.  Most of the other changes in this area came in
with bash-4.0.
----
        I thought (()) was a bash extension?

        If so, why shoe-horn it into a 20y/o spec**?  It's often used for
doing calculations -- that's why it was added... it can only be used
where a command can be used, so having it die whenever it evals to 0 -- just
doesn't make sense.  If there's an error in the calculation, like division
by zero, sure, but just because I come up with a result of 0, == it's a far
stretch to think that would be an error.


((sec=1,min=60*sec,hour=60*min,day=24*hour,year=365*day))
((testval=year-365*day)) ; script dies due to it being considered an error?

Did you get bitten by some POSIX virus?





Posix changed set -e to cause the shell to exit when any command fails,
not just when simple commands fail, as in versions of the standard up
to and including Posix.1-2008.
---
(()) isn't a command, it's a calculation (how's that for different justification?)


 There are the usual exceptions (command
following if, commands preceding && and ||, and so on).  This was
changed for better alignment with historical versions of the shell and
to reconcile differences between implementations.


2)  a function returning a false value  -- Tried putting the ((expr)) in
an if:

if ((expr)); then return 0; else return 1;

As soon as it sees the return 1, it exits, -- as I returned 'false'
(error).
----
        It was followed by an &&, has that changed too?

        i.e. must it be followed by an '||' (so the entire expression
comes out as 'true'?)



This should have always been the case -- a function is a simple command,
so its returning a non-zero exit status should cause the shell to exit.
This was true even before Posix changed.
----
        No wonder I'm going crazy....a bunch of changes went in that really
hurt functionality.

** -- wait, I thought posix was dead ages ago....there are updates? 2008? is that the latest? #*(@#$()@#)!@)*&% they whole reason for the standard was so programs
wouldn't keep breaking...and now they change the standards...

wonderful...
seems like that eliminates the justification for having a standard -- other than to force
everyone to rewrite and update to a new standard...hmmm....




reply via email to

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