Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16302

Re: behavior of arithmetic evaluation operator inside extended test operator

Path csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From Oğuz <oguzismailuysal@gmail.com>
Newsgroups gnu.bash.bug
Subject Re: behavior of arithmetic evaluation operator inside extended test operator
Date Tue, 19 May 2020 21:05:25 +0300
Lines 148
Approved bug-bash@gnu.org
Message-ID <mailman.579.1589911541.3227.bug-bash@gnu.org> (permalink)
References <CADNZbLQ8p9ggi3pzwY1LKk=O2T4_a9W2Awap3bXSzGQxhNN=uQ@mail.gmail.com> <20200519141033.GU751@eeg.ccf.org> <CADNZbLT2Fid=AMyJRPeXifnGKkTX0EcUJRuOcr8radY-jTHcuA@mail.gmail.com> <CAH7i3LpMRDpDpPQzoOa8Tt66C6NvLKP6QHuDjObS11EUVKN_Zg@mail.gmail.com>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset="UTF-8"
Content-Transfer-Encoding quoted-printable
X-Trace usenet.stanford.edu 1589911541 21962 209.51.188.17 (19 May 2020 18:05:41 GMT)
X-Complaints-To action@cs.stanford.edu
Cc bug-bash@gnu.org, wooledg@eeg.ccf.org
To Inian Vasanth <inian.vasanth@gmail.com>
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JuS5CrCxEIll1hA/DBoWbeITSnA3cOvnLjAQSc1WBBA=; b=lVpuG6MRmmy3XItHlA662dSnpsdCc6Is/cqDNrKDcTX3jLBS4r+K/HZcQ1KiF00F/s 9NpuigMOgGnPHhO5c8zcV/0thqzAA0iTOEAGAXpFRUH/gGMjWbZ5O0k9fu7m/dCedRaW MHjNq9fNlHfJNFhOVCbNGJ/4uBKrvYZZFzkaMovq1f+c/RrCovGeN3geVndIS+fNU5WM X+fke0AMdY1AG5Q14nlh/KL9leMui8EBVXHtbM848g1E7yliCiEmhgmT9P0W2KJAMnhK Q8mBE9f+H+4OdCpkAzYn4RESC4+9OtdZycxJhXhWxtsHECtU6fUId78oJpw57XX9daWz 8ChQ==
X-Google-DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JuS5CrCxEIll1hA/DBoWbeITSnA3cOvnLjAQSc1WBBA=; b=ldUblYU8SoYvd/j6miAXxeS2CEKYsMEwyVDe/yMVE+9vbKF1lL+gsAMp4TW3PS1NUm ZAYYNQA/+OSGs9F/q7TYvLjyIg0JIf9RbszvwLkmtTS6os/yoJMUz0wnyy/wbC+nAHWi FDsePmyVbq4ggzpOQbn6BA1mDtKLRN0XJtZF1arvUA2XcyDszrk3Ya8fA95su0yxx3lg FrVzKXGlb76lMHPS4ak64MS/jK9NhfWSe1owj5GeCXpFJ3p+jnk5T+lKDpQTnpQKippz qTErNdpU14EyrVDoVVlmIwp5K4p0PmaSzRKZ0LhL81Op1VVxqJx/hwBuWtHoOF6YcSzR koDw==
X-Gm-Message-State AOAM533ZS9l/T5XjxAmNWd4vEJJhXgNcvC9DH3HZpGvg2WsMHmqL61hG 524YJyUGRQ1T+Y6p2V7ur8xUzT9CU0k92vKYT6I=
X-Google-Smtp-Source ABdhPJxHcUwoB7sNfjbv2DTu2fnQ5BYunR0SBJxk8gxMGuFYwty7cGEs9HePPRYNUnr2IjiXKO7lk8sGiWPL0uzwtjQ=
X-Received by 2002:a05:620a:142:: with SMTP id e2mr619262qkn.331.1589911536520; Tue, 19 May 2020 11:05:36 -0700 (PDT)
In-Reply-To <CADNZbLT2Fid=AMyJRPeXifnGKkTX0EcUJRuOcr8radY-jTHcuA@mail.gmail.com>
Received-SPF pass client-ip=2607:f8b0:4864:20::729; envelope-from=oguzismailuysal@gmail.com; helo=mail-qk1-x729.google.com
X-detected-operating-system by eggs.gnu.org: No matching host in p0f cache. That's all we know.
X-Spam_score_int -10
X-Spam_score -1.1
X-Spam_bar -
X-Spam_report (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN
X-Spam_action no action
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <CAH7i3LpMRDpDpPQzoOa8Tt66C6NvLKP6QHuDjObS11EUVKN_Zg@mail.gmail.com>
X-Mailman-Original-References <CADNZbLQ8p9ggi3pzwY1LKk=O2T4_a9W2Awap3bXSzGQxhNN=uQ@mail.gmail.com> <20200519141033.GU751@eeg.ccf.org> <CADNZbLT2Fid=AMyJRPeXifnGKkTX0EcUJRuOcr8radY-jTHcuA@mail.gmail.com>
Xref csiph.com gnu.bash.bug:16302

Show key headers only | View raw


On Tue, May 19, 2020 at 8:36 PM Inian Vasanth <inian.vasanth@gmail.com> wrote:
>
> Thanks Greg for the explanation. Yes your explanation  aligns with my
> understanding too.
>
> My recommendation was to check if this behavior needs to be documented as a
> side-note in this section of
> http://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Bash-Conditional-Expressions
> to
> explain that, any other primaries other than the ones mentioned above will
> be evaluated as a literal string result.

I don't think that's necessary, under `[[…]]`, it says

    Expressions may be combined using the following operators, listed
in decreasing order of precedence:

    ( expression )
        Returns the value of expression. This may be used to override
the normal precedence of operators.

With that it shouldn't be that hard to figure out `[[ (( x < y )) ]]`
equals to `[[ x < y ]]` in function.

> I also tried finding an
> explanation in your wiki at
> https://mywiki.wooledge.org/BashGuide/TestsAndConditionals, but there
> wasn't an explicit point made.
>
> On Tue, May 19, 2020 at 7:40 PM Greg Wooledge <wooledg@eeg.ccf.org> wrote:
>
> > On Tue, May 19, 2020 at 06:10:30PM +0530, Inian Vasanth wrote:
> > > The behavior of arithmetic context operator $((..)) inside [[..]] is not
> > so
> > > well defined.
> >
> > It's simply a substitution.  The $(( )) is evaluated, and the result
> > is placed into the [[ ]] command as a word.
> >
> > > The downside is the operator
> > > without $ when used as ((..)) just behaves as double grouping,
> >
> > Correct, as you demonstrated below.
> >
> > > but $((..))
> > > behaves as a valid arithmetic evaluation followed by non empty string
> > > comparison `-n`
> >
> > Well, yes.  What did you *expect*?  What are you trying to do?
> >
> > > bash -cx '[[ (( 100 < 3 )) ]] && echo ok'
> > > + bash -cx '[[ (( 100 < 3 )) ]] && echo ok'
> > > + [[ 100 < 3 ]]
> > > + echo ok
> >
> > The parentheses here are doubly redundant.  You're performing a grouping,
> > but there is only one operator, so there's nothing to group *for*.  And
> > you're doing the grouping twice, for no discernable reason.
> >
> > You're also using the < operator in a [[ ]] command, which is string
> > comparison, not integer comparison.
> >
> > If your goal was simply "check whether the integer 100 is less than the
> > integer 3", you don't need to use the [[ ]] command at all.
> >
> > if ((100 < 3)); then
> >   echo ok
> > else
> >   echo not ok
> > fi
> >
> > If you insist on using [[ ]] for some reason, integer comparisons can be
> > forced with the -lt -gt (et al.) operators.
> >
> > if [[ 100 -lt 3 ]]; then
> > ...
> >
> > > bash -cx '[[ $(( 100 < 3 )) ]] && echo ok'
> > > + bash -cx '[[ $(( 100 < 3 )) ]] && echo ok'
> > > + [[ -n 0 ]]
> > > + echo ok
> > > ok
> >
> > Here, you are forcing an arithmetic substitution to be explicitly
> > performed,
> > before the [[ ]] command begins.  The result of the arithmetic substitution
> > is a word, and that word will be checked for non-zero-length by the [[
> > command.  It is exactly as if you had written:
> >
> > tmp=$((100 < 3))
> > [[ $tmp ]] && ...
> >
> > The form [[ $x ]] is just the same as [[ -n $x ]] and that's what you
> > have written here.
> >
> >
> > > bash -cx '[[ $(( 100 < 300 )) ]] && echo ok'
> > > + bash -cx '[[ $(( 100 < 300 )) ]] && echo ok'
> > > + [[ -n 1 ]]
> > > + echo ok
> > > ok
> >
> > Same.  It doesn't matter whether the result of the arithmetic expression
> > is 1 (true) or 0 (false), because both of these words are strings of
> > non-zero length.
> >
> > To repeat: if your goal is to compare integers, you should use one of
> > these forms:
> >
> > if ((x < y)); then ...
> >
> > if [[ $x -lt $y ]]; then ...
> >
> > if test "$x" -lt "$y"; then ...
> >
> > if [ "$x" -lt "$y" ]; then ...
> >
> >
> > Remember, the [ and [[ commands are just that: *commands*.  They are not
> > a part of the "if" syntax.  You don't *need* them every time you use
> > an "if".  You don't need to bend over backwards trying to work out how
> > to merge the command you actually want to use, together with the [[
> > command.
> >
> > Just omit the [[ if it's not the command you want.
> >
>
>
> --
> Regards,
> INIAN VASANTH P



-- 
Oğuz

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: behavior of arithmetic evaluation operator inside extended test operator Oğuz <oguzismailuysal@gmail.com> - 2020-05-19 21:05 +0300

csiph-web