[Top][All Lists]

[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 22:45:39 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Thunderbird/ Mnenhy/

Chet Ramey wrote:
On 8/9/11 8:10 PM, Linda Walsh wrote:

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?

It is.  That's not a reason to make `set -e' apply non-uniformly.
        But it's purpose was to do calculations, no?

        If you were doing calculations with a 'error checker turned on',
would like feel it was a good feature if everytime your calculator
displayed '0', it it quit?

        There is a reason to make it apply non-uniformly -- as
(()) really isn't a 'command', in that it's not a standard 'command word',
nor is it something that would be handled by an external program.

It is something specifically for calculating numeric values that one wouldn't want to crash a program that is detecting *error* conditions, since '0' is just
as valid an integer as any other.

If they want it to 'die', have them put 'test' in front of it, then 'test' can throw the error. But I'd have to think killing your script whenever you calc '0',
can't be a desirable feature.

There are ways around this, if it's an issue.
        Yes...rewriting bunches of scripts that use math ...

or things like (concocted case...), but you couldn't use the value of that statement
in an assignment, as it would get the 1.

if ((tmp<0)); then xxx

Did you get bitten by some POSIX virus?

That didn't end up being nearly as funny as you probably thought it
was going to be.
Oh...*gulp*...um...I hope it's nothing serious (at least not in a bad way)...
        Working Group Member?...Oh dear...I call conflict of interest!!!!  ;-)
(well, maybe not, but ... hard to see bash well represented...with that many other members, you could easily be 'borg'ized...(and next you're going to tell
        me that  <resistance is|objections are>   futile?))...

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

Creative, but it's a command.
        I don't regard a 'calculation' that returns 0 as an 'error', though.

That's a **subjective** and maybe speaking for no one other than myself, but is not a universal interpretation. It is a type of 'statement', but I don't see how it can
rightfully be called a command as it doesn't  'command' anything.
It's not starting programs, it's governing program flow -- it merely does
calculations on variables..

Now you may be referring to how it is handled semantically by the parser or such, but
that's also an internal design matter, not how it looks externally.

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'
    It was followed by an &&, has that changed too?

It's impossible to say what the problem, if any, might have been.

For instance, the following script displays `after':

set -e
        if (( 0 )); then return 0; else return 1; fi

func && echo a
echo after
        That can be justified though, fortunately, as && is your success, then
'after' is only a fail case where you can do error handling.

I had this:

#simple function to turn off tracing of some routines...as during devel, I
#was wanting to see things by default and turn off things by option...

  function DebugPush_helper {debug $1 || set +x ;}

Would cause my script to exit everytime something wasn't debug'ed...

(great, I turn off debug, and everything fails!)...

Of course one can work around it:

  function DebugPush_helper { if ! debug $1 ;then set +x ;fi; }

But again, 'surprise', it wasn't a simple command at the top level of the
script, but in a function!...took me forever to figure out that
return non 0 from a function was 'bad'....and should kill script by default..
(even when not called 'bare' at top level).

Maybe you should read it; you'll see that work is continuing.

        So I see...great...more incompats coming up I expect...
(only the pessimist side of me...part thinks it cool...I argue w/myself
all the time; side effect of growing up w/lawyer as father, and mother
w/masters in speech & communications ... iiieeee....)...


reply via email to

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